Proposal: Native Scripting Support (JS/Lua/mruby/Python/WASM?)

[JackDrogon]

Hi tmux community,

I’d like to propose adding native scripting language support to tmux to enhance customization and automation. While shell-based scripting with tmux commands works, a dedicated scripting interface could:

1. Simplify Complex Logic

   • Avoid fragile string manipulation in shell scripts.
   • Directly manipulate tmux objects (panes, windows, sessions) as structured data.

2. Improve Performance

   • Reduce overhead from frequent tmux command subprocess calls.

3. Enable Sharing & Plugins

   • Support shareable modules/plugins (e.g., Neovim’s Lua ecosystem).

Potential Language Options

Language	Pros	Cons
Lua (Neovim-style)	Lightweight, battle-tested, fast.	Limited stdlib, syntax may feel minimalistic.
mruby (Embedded Ruby)	Clean syntax, familiar to Rubyists, lightweight.	Smaller community than Lua/Python.
Python	Huge ecosystem, beginner-friendly.	Heavy runtime, dependency concerns.
WASM (Zellij-style)	Cross-language, sandboxed, secure.	Higher complexity, newer to terminal tooling.
Custom DSL	Tmux-specific, no dependencies.	New syntax to learn, maintenance cost.

Why Consider mruby?

• Lightweight: Designed for embedding (unlike full Ruby).
• Familiar Syntax: More expressive than Lua, less verbose than Python.
• Proven Use Cases: Used in ngx_mruby (Nginx).

Example Use Cases

1. Dynamic Layouts: Auto-adjust panes based on window size.
2. Session Templates: Interactive setup with prompts.
3. Event Hooks: e.g., on-client-attached to trigger scripts.

Discussion Questions

1. Is there interest in native scripting support?
2. Preferred language (Lua/mruby/Python/WASM/DSL)?
3. Should this be optional (compile-time flag)?
4. How to balance power vs. complexity? (e.g., mruby vs. WASM)

I’m happy to prototype this if the idea aligns with tmux’s direction. Projects like Zellij’s WASM and Neovim’s Lua show demand for deeper extensibility.

[nicm]

This is a difficult one.

I am not completely opposed to this idea, I would quite like to be able to get rid of or simplify a lot of the stuff that tmux does itself like command parsing, hooks, etc, and delegate them to an embedded language. However, it would be difficult. There are a couple of major issues:

---

The first is that importing any kind of scripting language into the base system would be a very hard sell. It was discussed a long time ago for mg - there was mention of Lua, as well as some Scheme or Lisp variant. I said then that if a scripting language was imported for mg I would use it for tmux, but IIRC the discussion faded away without resolution. Still, my impression was there was little enthusiasm for the idea.

So, the best approach would be to do it in such a way that only portable is impacted, meaning that OpenBSD tmux continues to work. Any use of an embedded language would need to be optional, to parallel existing features, or extend them, rather than replacing them.

But I definitely don't want that forever - the point of an embedded language is to make things simpler and more flexible, not to have two ways of doing everything. So at some point in the future once the integration was proven, we would have to make a decision whether to try to get the language imported into OpenBSD, or to keep it as optional but remove some features if built without, basically having "tmux" and "tmux-light".

---

The second issue that this would be a lot of work, multiple years, and it would need to be done carefully. It is not easy to properly integrate an embedded language into an existing C program, and I've seen it fail before. So I would like to see a plan for how it would look, what features would be added, extended, replaced, and in what order, and so on.

As far as languages go:

• I would personally most like Python because it is sensible and I've used it for a long time, including the C API. But it is far too big so it is probably out.

• I don't know Lua well but has a track record for this kind of thing and IIRC is quite small so might work.

• I haven't used Ruby for 20 years or so but I had a quick look at mruby and it looks pretty small so it might be possible.

• WebAssembly is a joke, so no.

[JackDrogon]

Based on your response above, I have narrowed down the choice of scripting languages to Lua and mruby. Lua has two versions: one is from lua.org/lua, and the other is LuaJIT. In terms of performance, LuaJIT is superior. Personally, I don't particularly like Lua, it's just too cumbersome to write. Neovim chose Lua because Luajit's performance is outstanding.
mruby only depends on libc and can even run on embedded systems. In terms of language friendliness, I personally prefer MrRuby.

Besides these two languages, perhaps the JavaScript implementation quickjs could also be considered as an option.