alternative configuration language

[Sparkenstein]

Started using this terminal recently, it's been amazing so far.
at start I faced problems on my i3 wm, the keybindings were colliding with i3's default keybindings and few of the default keybindings were not working as given in the docs as well, So I had to re map multiple things as per my convenience kudos to the docs it was really easy. 🥳

But the process of configuration relies on knowing lua, which I didn't know at all, so just for the sake of configuring my terminal
I had to dive into basics of lua. I doubt everyone will have time or energy to learn lua which becomes one of the main reason for people to stop using this terminal. Why did you pick lua if I may ask. Do you have any plan for alternative configuration language?

PS: I want to share this with community, would you mind if I share it on reddit etc places

[bew]

I doubt everyone will have time or energy to learn lua which becomes one of the main reason for people to stop using this terminal.

I'd say, so be it..
The Lua language is a simple language the whole documentation is pretty short compared to other languages, and it allows you to have almost arbitrarily specific configurations which is god-sent for power-users (like me).
In addition to that, the Lua language is easy to embed in an application and has a small memory/complexity footprint.

To get a basic terminal config it's pretty easy, and you don't need to know Lua a lot, assigning values to a table is enough.
Like return { foo = "bar", }.
If you want something a little bit more complex like rewriting all you key / mouse bindings, using custom events or implement custom actions, make a dynamic config per window, or have a single multi-platform config, you need a simple programming language where Lua fits perfectly in my opinion.

---

few of the default keybindings were not working as given in the docs

This may be because the default keybindings are tailored to a qwerty keyboard layout

[Sparkenstein]

lua is amazing no doubt, it's prolly the best bet for embedded languages, but it even a small learning is a learning curve which I would prefer to avoid if that's an option. currently my config looks like this

local mykeys = {}
  for i = 1, 9 do
      table.insert(mykeys, {
          key=tostring(i),
          mods="CTRL|SHIFT",
          action=wezterm.action{ActivateTab=i-1},
      })
 
      table.insert(mykeys, {
          key="F" .. tostring(i),
          action=wezterm.action{ActivateTab=i-1},
      })
 
  end

this code is copied directly from docs, without docs, it would take like half an hour to google and understand how "map" (table here) works in lua, and then implement it, debug it, customize it. guess what, this code is exactly same as

{
  "keys" : [
         {
           "key": "F1",
           "modifier": "Ctrl|Shift",
           "action": "ActivateTab1"
        }
    ]
}

or

[[keys]]
key = 'F1'
modifier = 'Ctrl|Shift'
action = 'ActivateTab1'

This will grow configuration size rapidly no doubt, but it will also ease the time it require to configure anything.

Note that the question here is 'should wezterm support another way of configuration', not 'wezterm should remove lua' etc, I have no problem with lua in any case.

if you still want some programming language, I can suggest QuickJS it's a 600kb js runtime, even smaller than lua and js is widely known than lua, but then again the problem remains the same, with any programming language, people who don't know that language, will have to learn it. (just like any configuration language like yaml or toml but they have much smaller learning curve)

[jankatins]

This will grow configuration size rapidly no doubt, but it will also ease the time it require to configure anything.

The above is more advanced because it contains a for loop but if you would write that in a similar manner as you would suggest it will end up looking almost the same as the JSON:

return {
  keys = {
    {key="1", mods="SHIFT|CTRL", action=wezterm.action{ActivateTab=1}},
    {key="2", mods="SHIFT|CTRL", action=wezterm.action{ActivateTab=2}},
    [...]
 },
}

If you want/need a fancy terminal like wezterm, then learning that (small) bit of lua (or better do a bit of trial&error when adapting stuff) is IMO some well spent time. Gaining the ability to do all kind of flexible, time saving magic is a nice tradeoff.

[wez]

wezterm started out with a TOML configuration file, but quickly outgrew it as the feature-set got richer.
I selected Lua for a number of reasons:

• In the basic cases, it is a simple declarative language that does what you'd expect
• It is surprisingly powerful, with support for closures and yielding, which allows users to express complex logic (if they wish)
• Lua allows wezterm to manage async/await transparently. A number of functions exported from the wezterm module are implicitly asynchronous and don't block wezterm. That means that complex and horrible promise based programming doesn't bleed into the configuration file.
• Lua is made for embedding. I've embedded php, perl, python, java, js and written FFI for COM and ObjC and stuck those things in other languages and made those things all call through to each other over the years. None of them are as straightforward to integrate as lua.

So, lua support isn't going anywhere. As to your question about also supporting something else:

As I mentioned, we started out with TOML, and then grew Lua support. For a few releases we supported both of these, but having two different config sources was bad because:

• The documentation was now twice as complex for readers to consume, having two different ways to express each concept, and twice as much effort for me to write.
• Some features were only expressible in Lua
• A number of core features like key assignments were limited by how expressive the TOML file could be, and it was holding back feature development
• There were two different code paths for loading configuration, which was difficult to maintain and at least doubled the effort of adding new things.

Given the increased complexity both for development and for users, I'd say the chances of adding another config source are close to zero!

I hear what you're saying though: I think it would be reasonable to adjust the docs to show the "boring" hand-unrolled version of the config to demonstrate what is being added to the config file, and then follow up with a little block that shows how to use a loop to make it more compact/easier to maintain.

PS: I want to share this with community, would you mind if I share it on reddit etc places

Please do!