Support workspaces

[gegoune]

One feature I heavily rely on in Wezterm is workspaces. Workspaces are great, they allow me to keep related tabs organised into logical groups. Such as: working on issue n, working on project p, etc. Wezterm also allows automating creation of those through APIs which allows me to write solution such as: on keybinding press: create named workspace or switch to it exists, create tabs and panes, run specific commands in specific panes. This is great.

I have moved to Wezterm from Alacritty because workspaces alleviated need for tmux (or other multiplexer).

I would love to see similar feature in Ghostty. What do you think? Is it feasible at all? Does it align with your vision of Ghostty's future at all?

[mitchellh]

Thank you! It's an interesting idea. I'm not opposed it to it at all in principle, but I think I want to consider the larger implications first (i.e. is this to replace tmux? if so, are there other approaches to consider?). Or in other words I'd like to take a step back and ask "why" 5 times to understand if this is really the solution we want in Ghostty to solve all the various problems we discover, rather than blindly copying another terminal emulator in this case.

It certainly aligns with Ghostty's future in the sense that I want Ghostty to solve problems people have and to be feature rich.

I think this overlaps a bit with #601 as well. Workspaces are NOT that, and I get it, but some of what you mentioned in the original issue is covered by #601.

I think for now, if you're okay with it, I'd like to close this. I'm happy to continue the discussion in the closed issue, I remain active in those, but I don't think this is planned in the near future with all the other TODOs, and I think some of this fits discussion also may fit into other issues too.

[ferdinandyb]

I'd also like to chirp in on this. I'd be extremely happy to be able to completely ditch tmux, because as great as it is, by it's nature of sitting between the terminal and the running application it makes things slow and it basically also strips away any fancy feature of the host terminal that tmux itself does not implement.

Tmux has a ton of features, some via plugins, so this is probably a pretty biased list, but for me these would be the features that I'd need in a terminal to be able to drop tmux:

• named sessions (instead of just tabs and splits, or in tmux parlance windows and panes), that can be put into the background
• do this with remote sessions as well (wezterm can do something like this as I discovered today)
• statusline so you know where you are (contour has a statusline based on DEC VT320, which seems like a long-lost standard?)

And of course handling the scrollback and some fancy search functions are also cool, but seeing that there's an open issue about search, I think I'll post about that there.

[ferdinandyb]

Seeing that wezterm is the only one out there that sort of has it all I took it for a spin. There's at least two things that could be done better imho (other than it's ssh connection being buggy and messing up vim ...):

• you need to preconfigure your "ssh domains" in the config file, you can't just go and randomly connect to some remote computer (not to mention it knows nothing about ~/.ssh/config)
• the server side has to have a strictly matching version of wezterm installed and I'm pretty sure that is unnecessarily strict

[gegoune]

@ferdinandyb Please note that ssh domains are a different feature to workspaces. Or am I missing anything here?

[ferdinandyb]

@gegoune Well yes, they are different things, but @mitchellh also asked "is this to replace tmux?", so I sort of went along with "yes" :)

So I imagine you'd have workspaces and you'd have ghostty being able to function as an ssh client, and then to be able to completely drop tmux, you'd need to be able to spawn (and persist) workspaces on the remote machine and connect to them via ssh. I mean I do use tmux locally as well for now, but it's way more useful remotely, especially with flaky connections.

[jcollie]

I think persisting sessions on remote servers would be out of the scope of a terminal emulator... You'd have to have Ghostty installed on the remote system just to begin with, as trying to automatically install Ghostty on the remote system is just FRAUGHT with problems. I personally don't even really want Ghostty persisting local sessions.

[ferdinandyb]

@jcollie (For clarification: I'm obviously arguing with the assumption that people want persistent remote sessions in some way and are currently users of tmux/zellij/screen or something similar, let me know if you're also contesting that.)

• You're already installing tmux on the remote system. Automatic install would of course be very problematic, but I doubt there's a need. If ghostty becomes popular enough, it will be preinstalled like tmux, otherwise when you first connect, you'll need to set up terminfo anyway. And tmux being preinstalled isn't that reliable either, I've had to build it countless times when it was preinstalled but ancient ...
• Should ghostty get the ability to persist sessions locally, then having to learn two sets of keybinding, configs etc for having that ability remotely is not a nice experience. Sort of similar arguments for splits as well, but of course there you have an easier way: let the OS handle "workspaces" by starting new instances and if you are in an ssh session and make a split just run the same ssh command again (although I'm usually afraid to run anything that takes more than 10 seconds in a non-tmuxed ssh session).
• Session persistence actually doesn't need to be explicitly ghostty. It could be just managing something like monomux and ssh (and local) sessions (for each pty) in the background. Monomux doesn't do the whole "reinterpret output" thing, so it's neither slowing things down, nor messing up features it has not implemented itself.

tldr; I feel it is hard adopt terminal innovations if you feel tied to tmux for persistent remote sessions :( Case in point, that tmux just got sixels like two months ago or something?

[ferdinandyb]

I've been thinking about this a bit more. Actually, with wezterm's current solution, the biggest problem isn't installing wezterm on the server: it's that you actually need wezterm on the client machine, meaning that if you start a session from your laptop, but would need to access it from your phone later on, with tmux you just need a plain old ssh client, with wezterm mux server, you just can't.

I could totally imagine a very generic mux server, that allocates and persists ptys and exposes a rather generic API, where you can query which ptys are in which splits, tabs, sessions and allow you to connect to one of it's pty-s from shell. And then any client terminal (or tmux), that speaks this could query the sessions/layouts, recreate the tab/split layout for a session and connect to the ptys to the corresponding splits. This would mean that if you have a "fancy" terminal you could get all the goodies without a middleman like tmux, and if you are not, you can still spin up tmux and connect to the same thing.

Nota bene: my understanding of terminals and ptys is pretty vague, so this might totally unfeasible for several reasons.

[PeterCardenas]

this sounds like tmux control mode maybe?

[ferdinandyb]

hmm, it indeed may sound like that?

[ferdinandyb]

I mean, I sort of read through it now, but I feel out of my depth to understand any technical limitations (speed, etc), but the first paragraph definitely sounds like something very similar.

[ferdinandyb]

So I started poking at the tmux control mode. Unfortunately it turns out my understanding of this topic is currently not enough to properly check, but it does seem like tmux will still parse vt sequences even in control mode, which is not ideal (but as I said, I wasn't able to explicitly check this). I'm also going to quote @christianparpart (contour author) on this: the text based protocol is very naive and at the very least should be reworked if it would want to support other clients. I'll also quote him on that he said that in the future he could imagine collaborating on a terminal-agnostic daemon protocol with interested terminal authors @mitchellh :)

[matthewp]

Chiming in here. The reason why I want this feature is also to replace tmux. I also don't care about the ability to run remotely; tmux is still fine for that use-case. But the primary reason I have used tmux is to have persistent sessions on my own machine, and the ability to group different workspaces for the various things I'm doing. For example I almost always have sessions for:

• mail (Neomutt)
• file browsing (yazi)
• notes (any text editor)

I don't need/want to see those in a tab all of the time, so they live in their own session and I can easy toggle between them.

Wezterm does a pretty good job here as others have mentioned. For me it's enough to give up tmux, which has the compatibility and performance issues already known.

[nfejzic]

There's a workaround for those who want to use Ghostty without tmux or zellij but still have some support for sessions:

You can configure your shell to include the current directory in the title bar. I configured this to include at least 2 parent directories as well. You then open multiple windows and use some kind of window switcher (e.g. Raycast on macos has switch windows command) and fuzzy search for that directory.

My sessions were named after the (main) working directory anyways, so this works well for me.

This might not work well for you if you use arbitrary session name and open various different directories in the same session. However, you might be able to find a way to modify how your shell sets the title so that you somehow include session name there.
One possibility would be for Ghostty to create GHOSTTY_WINDOW_ID env variable per window for and we could write small script or program that maintains mappings of window to session name.

This would let us take advantage of other tools to have a working solution for workspaces until this gets natively implemented.

[fredrikaverpil]

I too dropped tmux in favour for Wezterm's workspaces. I think the workspaces are excellent and can be set up so to provides fuzzy searching with fzf if you add smart_workspace_switcher.wezterm. This achieves very similar functionality as when using sesh, but without tmux and the visible latency when drawing the screen.
I actually did a writeup about it here: https://fredrikaverpil.github.io/blog/2024/10/20/session-management-in-wezterm-without-tmux/

Now that I have access to Ghostty I was curious to see what options there might be to switch between projects (hopefully using fzf in some way).

@nfejzic Are you still using Raycast to find existing windows?
What about creating new windows (from a fuzzy search)?

[nfejzic]

@nfejzic Are you still using Raycast to find existing windows? What about creating new windows (from a fuzzy search)?

Hey @fredrikaverpil, so what I've found is that Tmux has more features that I find useful, not only session and window management. For example, I can enter scroll/selection mode with vi bindings to select text on screen, scroll back etc. I find that very useful (Wezterm has that as well!).

So for now I went back to Tmux because of multiple reasons (sessionizer, selection, search etc.). This is not ideal, because Tmux introduces some overhead. I also could not go back to Wezterm because I use wayland and that part is being reimplemented in Wezterm so it's not working great right now.

I think Wezterm is one of the most feature-packed terminals out there, and that could be used as inspiration for Ghostty.

[fredrikaverpil]

@nfejzic I think I'm in a similar spot as you. I don't really want to back to Wezterm as Ghostty is just so much faster in terms of perceived latency and is such a great quality of life when zipping through buffers. But I also can't find any other way to manage several "sessions" without resorting to tabs or windows (which is not as efficient as flipping back and forth between "sessions" or "workspaces" using fzf).

When comparing tmux + Wezterm against tmux + Ghostty, it's ok for the most part with the latter combo. It's just when I open up new buffers or scroll through large amount of text that it becomes apparent that tmux is making the screen refresh/drawing perceivable and introduces stuttering which makes for a janky experience.

I wonder if the tmux control mode improve this experience or not.