Suggestion: Session manager

[PbVrCt]

I listened to a recent interview with Mitchell: He thinks it would be better if multiplexers like tmux and zellij became obsolete in favor of something with an arquitecture more similar to ghostty.

Since this is desired, I suggest providing some session manager like functionality.

What I use:
https://github.com/joshmedeski/sesh
Zellij has a default session manager, which I have tried, but the one I linked provides a way more frictionless experience.

How do I use a session manager:
I use it to switch between different tmux sessions. Each session has a neovim like IDE open on a code repository, and maybe a few other windows (I believe the ghostty equivalent of a tmux window is a tab).

With one keybinding, the session manager brings up a fuzzy finder with all the open sessions. I also have a keybinding to toggle between the 2 most recent ones. This allows me to switch context between repos quickly and thoughtlessly.

I also use it to start sessions, because it can fuzzy find paths and start a session at the directory you choose. I have set it to look at the subfolders of the folder where I clone repos on my laptop, as well as my config files folder.

Common usecases:
Both switching to or starting new sessions is low friction:
I often use it to take a quick glance at a repo that I'm taking inspiration from, or to browse a repo I just found on Github from my IDE.

Thanks:
Thank you to Mitchell for creating this.
I specially like the zero configuration philosophy.

[SuperDuperDeou]

I completely agree with this take: terminal multiplexers are just a relic of the times when terminals were hardware and the feature set was small. In modern times, they just make supporting advanced features more complicated than it needs to.

Ghostty already does the actual multiplexing (tabs and splits) on its own, that already covers the reasons why terminal multiplexers
exist in the first place, and would only use one just for session management, with all the overhead and issues that come with using a terminal multiplexer.

Having session management inside of Ghostty would make so the only use case for a multiplexer is to run one on the server inside of an ssh connection, which is fine: you can't expect to use advanced terminal features inside of an ssh connection.

[akda5id]

There are multiple parts of this problem, and the terminology is a bit confused around what to call each part. So I'll briefly run though how I see it, and the terminology as I understand it, as a contribution to this discussion.

I see terminal multiplexing as providing the surfaces that the terminal then renders the shells in. I think the standard term for this is "pane", and ghostty I guess calls these "splits", which is a bit ambiguous, as a "pane" could be a whole window, or tab if there are no splits in that space, but if there is, what do you call each part of the split? But as far as features for the basic multiplexing, I think Ghostty is pretty much there, with the one part that might be considered missing is a way to move around splits. #1525

Moving on from there is the ability to restore a grouping of windows, tabs and splits. Ghostty has this, in the single case of closing the application, and restoring windows existing when closed. But no ability to restore the contents inside the shell, basically you get a new shell. OS X's Terminal.app has a very elegant way to handle this, restoring the scrollback and command history per window. Lilyball has an interesting writeup of that here: #2679. With the implementation of the TERM_SESSION_ID env var, we could get the command history restoration for free, leveraging the shell. It's not clear to me how the scrollback restoration works, I believe that is something the terminal handles, and this makes sense to keep there, as it would need some integration, or be a horrible kludge. (but, if we had a unique ID in the vein of TERM_SESSION_ID, the user could use other session management tools to save and restore to windows themselves.) Issue for the scrollback side of things: #1847

Then we reach the topic of discussion, a method of saving states of these groupings, and the contents within, at user direction, and some management of these states. I think the previous two parts are necessary for any session to exist, so they need some attention first, but it would be good to know the direction intended to make sure the implementation makes sense for the desired end goal. This would be things like at what level of granularity should a session be? Just splits within a tab? Tabs and their splits within a window? (My vote). Or all open windows at once?

[SuperDuperDeou]

The goal is goal of this feature request is to replicate the workflow that you would get with a terminal multiplexer.

For the granularity, GNU Screen was first release in 1987, when hardware terminals were still a thing, and software terminal emulators with tabs and splits wouldn't come much later. At the time, one GNU Screen session corresponded to one hardware terminal or to one terminal emulator window. In a more modern workflow, one Tmux or Zellij session would correspond to one window of a non-multiplexiing terminal (Foot, Xterm, st, Alacritty, etc).

The analogue of the window for a non-multiplexing terminal in a multiplexing terminal (ex. Ghostty, Kitty, Konsole) is, well, still the OS window. So, a window should be a session.

As for the session management itself, there are three aspects to consider (aside of the UI): initialization, reattachment, and restoration

Session Initialization

This is setting up a working environment, --command can be thought of as a very minimal and limited session initialization. There is no way for a window to set up a completely different session, because session initialization is considered config, and config is as the process level.

Windows should be able to run their own session initialization scripts instead of being confined to the command config of the process.

This is related to #3880

Session Reattachment

IMHO, this is the primary selling point of session management in terminal multiplexers.

When you kill a terminal running a terminal multiplexer, you do not actually kill the shell: the terminal multiplexer is still running in the background, and the shells were running inside the multiplexer, so they never got orphaned and killed. Then, a new terminal can connect to the multiplexer, and will display the same exact instance of the same shells.

Ghostty can already run heedlessly (--initial-window=false --quit-after-last-window-closed=false), so session reattachment can be implemented in a similar way as way as with terminal multiplexers: when the user kills the window, none of the processes that were running get killed, and the scrollback buffer doesn't get freed from memory, everything is still running within the Ghostty process as if the window was never killed in the first place, except there's no window.

Then, when the user presses a keybinding and selects the headless session, the session existing in the window gets detached, and the old session, still running, and its relative scrollback buffer(s) get attached to that window.

This requires to figure out two steps:

• How to keep the "window" (session) running without the window
• How to attach the session to a window

Session Restoration

IMHO, this one isn't very important and it's not even a requirement.

This would allow serialization of the window state to disk, with the ability to open a session look-alike with the same scrollback buffers, but new instances of the shells.

[cpossinger]

This is a tough problem if you want to keep the zero config philosophy.

In my experience plain text session config is sort of clumsy like in kitty or zellij kdl

I like how wezterm uses Lua apis to manage stuff but it's too much if you want to do something simple.

I think the easiest user experience is to do work in a project with splits/tabs etc and save that session with a built in session manager then be able to reference it later sort of like a mini crud interface.

[H-M-H]

Some more thoughts on session management.

As of now there are many terminal multiplexers like tmux, zellij or wezterm. I believe there is a lot of shared functionality. Namely:

• management of PTYs and their lifetime
• storing some kind of state required for reattaching to a session, such as
  • previous output
  • panes and their layout, possibly tabs
• protocol for inter process or even network communication with clients

I think this functionality could/should be implemented as server, independent of a specific client. Right now it feels like it used to be with IDEs and code completion. Everyone had their custom completion builtin. Now we have language servers, decoupled from the IDE.

Tools like shpool, diss or abduco look interesting, as they could serve as starting point for such a server.

In conclusion, I think there is a more general solution to session management than building it directly into ghostty.

[linkarzu]

• I'm also highly interested in testing Ghostty out without tmux in the way, I use tmux basically the entire day, as soon as I open Ghostty, tmux takes over with this command
• I use the tmux-resurrect plugin so all my sessions are restored when I close and re-open Ghostty
• I use tmux to easily switch between my different github repos, I use ThePrimeagen's tmux-sessionizer
• So with keymaps I jump to my different projects hyper+t+j -> dotfiles, hyper+t+u obsidian repo, hyper+t+l -> blogpost, hyper+t+r -> daily note, etc, etc
• Also with hyper+t+n I get an fzf menu of my different directories, so I can create a session out of any of those that I don't have keymaps for. And I just switch to them using the tmux sessions window (image below)
• Also if I tap left_shift on my keyboard, I jump back to the previous or alternate tmux session
• I honestly don't care about remote servers via SSH, my main goal is the session management features, if on a remote server I'll use tmux in that case, but I'd like to have a session management option in Ghostty to use the native terminal instead of basically be using tmux

[PbVrCt]

I also landed on this setup because of ThePrimagen. I took his "Developer Productivity" course.

[linkarzu]

I watched his "My Developer Workflow - How I use i3, tmux, and vim" video and that's what started it all, that's what started my macOS ricing and Neovim journey