In short. At the end of part 1 I wrote that "WezTerm's splits do not have this property. Close the window and the work inside it ends." That was only true of the default configuration. One line of config and the work inside keeps running when you close the window. The split layout comes back with it. I am writing down exactly what I confirmed on my own PC.
A free app I built myself. Give it a try.
Close the window and the build keeps going
Start a command in a terminal window and closing the window kills the command. The window and the program are one thing.
The two can be separated. A separate server running in the background holds the program. The window becomes a pane of glass you look through. Take the glass away and the inside keeps running. Put it back and even the output that accumulated meanwhile is there.
It is easiest to picture with a situation. You split the screen three ways. dotnet build runs on the left, the log is at the top right, and a shell sits at the bottom right. The build takes about ten minutes. Close the window here and
- the build is not interrupted and carries on,
- reopening later brings those three panes back, sizes included, and
- the output from before you closed is still there.
It is the same in three other cases. The terminal hangs, you edit the config and need a restart, or you close the window by mistake. Attach a new window and you are back where you were.
In part 1 I wrote that tmux is confined to the Linux world it runs inside. The server holding the work here is a Windows program, so that limit does not apply. Run Git Bash in one pane or a .NET build under PowerShell in another and both survive the same way.
One line of config and two shortcuts
Add one line to ~/.wezterm.lua that defines a session. mux is a name I chose, so use whatever you like.
config.unix_domains = { { name = "mux" } }That line alone changes nothing. WezTerm still opens as an ordinary window, and whether you enter the session is decided each time. So give it one shortcut in and one out. The leader helper from part 1 is used as is.
leader("a", act.AttachDomain("mux")) -- attach to the session
leader("e", act.DetachDomain("CurrentPaneDomain")) -- detach from the sessionYou do not have to start the server yourself; it comes up on the first attach. If the session is empty it starts with a single pane. If a session is already in use it restores that layout.
The order for closing and reviving
- Save the config above. It takes effect the moment you save.
- Attach with
Ctrl+Uthena. The first time it starts with one pane. - Split the screen and start the build as usual. The
Ctrl+Uthenw,vfrom part 1 work unchanged. - Detach with
Ctrl+Uthene. Simply closing the window gives the same result. - Press
Ctrl+Uthenaagain. The layout you set up comes back.
Here is what I confirmed. With the screen split three ways I closed the window and attached again. The size of each pane was identical to the character. The lines printed before closing were still there. The server process stayed up the whole time no window existed.
It is normal that closing the window in step 4 looks the same as pressing e. If the window holds nothing but session panes, detaching the session leaves nothing in that window.
Two things to watch. What holds the work is a server process running on your PC. It disappears when you shut down or restart the machine. Closing a window and turning off the computer are not the same thing. Closing the window does not end the session. To really stop the work, close each pane.
Summary
Separate the window from the program and a build carries on after you close the window. The split layout comes back too. The config is one line and getting in and out is two shortcuts. One of the points where I said tmux was still ahead in part 1 disappears with this.
Add the line and press Ctrl+U then a. Splitting the screen, detaching and coming back takes five minutes.