Tmux-like Wezterm Multiplexing Sessions

[kitten]

I worked on a little implementation of Tmux-like sessions for Wezterm via a quick and dirty shell script, and I'd love to show it off here for multiple reasons, but mainly because I think it could start some discussions and there was some interest in this already.

Please do chime in to tell me there's an easier way to implement this, if there is 😆 I've gone off of the existing docs and information from issues and discussion threads, but I haven't read the wezterm codebase extensively, so I'm just learning more about it by doing this.

Mainly, I've seen that two prior discussions relate to this topic:

• Attach new tab/pane to existing window? #1017
• Can it detach? #712
• How to start a new multiplexer domain? #1318

How my script works is pretty similar to a tmux-like workflow:

• New wezterm-mux-servers must be spawnable as daemons
• It must be possible to close/end/kill sessions selectively when a command is invoked
• The session must die when the wezterm-mux-server instance dies
• I must be able to list out all open sessions
• I must be able to attach to running sessions

To just get to the point, here is the script in question: https://github.com/kitten/nix-system/blob/abe3322f8991fe54e681f091d7e3bd438fcb60df/config/scripts/wezmux.sh

How does it work?

This script "exploits" the existing unix_domains config. It does not integrate with Wezterm itself that well, and instead runs wezterm or wezterm-mux-server manually. I'm on macOS, hence I haven't spent too much time on launching new Wezterm GUIs on other platforms, since on macOS I can simply call open -a ... --args, which isn't perfect but works for now.

All sessions are kept in .local/share/wezterm/sessions/*. Each session has a folder that contains a pid file with the daemon's PID, and a logfile. Creating the sock socket file is a responsibility of wezterm-mux-server itself. I don't let the server daemonize itself, but instead, the bash script itself becomes a small "faux daemon" and puts its own PID into the pid file.

Because of the folder structure, I can list out running sessions. Each time a new session is created, the bash script spawns a daemonized version of itself that traps exit signals to a small callback function that cleans up the session folder, and terminates the wezterm-mux-server as needed. The wexterm-mux-server is started with an overriden --config "unix_domains=..." config entry, which points at this new sessions/*/ folder.

The main script can then attach to the sessions by launching the GUI executable directly, on macOS via: open -a $WEZTERM_EXECUTABLE -n --args ....

What I've discovered is that this workflow is actually extremely comparable to tmux. I can launch a Wezterm window without a mux server (which I call default) and use it to create new sessions and attach to those. Once the session's Wezterm GUI window is spawned, I can exit the default (sessionless) window manually. The session stays active even when I close this new window and I can repeatedly attach to it.

How well does it integrate?

There's a bunch of things I do to my wezterm.lua configuration to make this a little easier to handle.
I had to, for instance, create a small status_right modification that reads unix_domains to display the currently active session's name: https://github.com/kitten/nix-system/blob/abe3322f8991fe54e681f091d7e3bd438fcb60df/config/home/wezterm/init.lua#L5-L13

Apart from that there's several things that I wish I could do:

• Wezterm has an open GUI socket for the active window, but I can't open a window in the currently running instance of wezterm and pass it the unix domain to connect to
• Wezterm has a launcher menu, but I believe it'd be a little hacky at best to update its content (if that's possible; there's no event for it, so it'd have to override the window's config periodically?) to add entries for all running sessions
• Wezterm can't detach/reattach the current GUI to and from sessions when it's connected to domains (or kill the active window programmatically). This isn't that big of a deal and an addition of opening new windows for sockets would maybe make this obsolete 🤔

So, I'm personally pretty happy with this admittedly super hacky solution 😄, but I think this could hopefully help form a better idea of what capabilities the GUI is lacking, in terms of its API and the GUI socket.

[wez]

Thanks for putting this together!

I'm going to digest this a bit. I'd love to hear what thoughts you have on making this sort of functionality a first-class thing in wezterm; especially the parts that were awkward or that don't work quite how you'd like them to in your mux script!

[wez]

The status area only exists to the right of tabs today. I don't have any plans to add other kinds of status areas.

[gegoune]

Perhaps I could tempt you a bit with approach such as status bar being fully configurable and tab being returned by some function, and instead of having set_right_status one would use some delimiter character. Something similar to vim's status line maybe?

Reason why I am asking about that is because I would like to have menubar such as:

[workspacename] [tabs] >(right hand)[time/date]

[wez]

I'm not keen to parse things out of text like that, but I'm open to the idea of adding an official left status bar; please file an enhancement issue for that.

[gegoune]

Is there any way to interactively create new workspace with key mapping (with being asked for workspace name)?

[wez]

Not directly in the UI. The closest you could get today is wezterm cli spawn --new-window --workspace NAME; that will create a window in the workspace but not activate it.

[joexue]

Let's have the "tmux -CC " please, then all are resolved.

[cazador481]

An ability to rename an existing workspace would be nice.

[zyriab]

You can do it now with wezterm cli rename-workspace your_name

[michaelbrusegard]

Would it be possible to setup workspaces to be tied to a single window (and not hide other windows) in a similar manner to how it is done in tmux sessions. I tried using workspaces, but they can be annoying when using a tiling window manager. If I have a wezterm window open on another desktop it will also be hidden when I switch workspace., and when I reopen the workspace all the windows become a mess because of the tiling window manager. I really like using wezterm so far, and having sessions would be lovely