alacritty

alacritty copied to clipboard

Now that multi-window support is on the roadmap, how about support for control mode in tmux? (tmux -CC) Essentially this allows the user to attach to a tmux session but instead of showing the ncurses UI in the same terminal window the terminal emulator opens actual windows for each window in the tmux session. Those windows then act as if they were normal terminal windows except detaching from the tmux session closes them.

How exactly does this work behind the scenes?

Nothing would stop anyone from setting tmux as a shell and attaching to different sessions from different terminals using the command parameter.

Basically the terminal emulator would mainly provide rendering and input and the actual terminal emulation is done by tmux AFAIK. iTerm2 has probably the most well known implementation of this.

The main difference to just setting tmux as the shell is that with control mode you get an actual terminal emulator window for all windows in the attached tmux session as opposed to having the tmux UI in your terminal. This means you have "native" scrollback etc.

You should be able to do that with a shell though, shouldn't you?

A shell could absolutely connect to a remote session without having to do any special curses rendering. After all most shells aren't actually doing any rendering at all.

Not sure what you mean? The point here is having a nicer interface for a persistent tmux session, be it local or remote.

I'm saying that I'm not sure why tmux requires special integration here instead of hooking into what is already available.

Since tmux is a specific program only used by some people, adding a special workaround just for that seems a bit unfortunate.

I mean I have no idea how you'd get a persistent reattachable session with a shell.

But okay. This issue was meant partially as a feature request and partially to gauge interest in the feature. If it's considered out of scope for alacritty that answers it. Feel free to close the issue.

I'm primarily trying to gauge what exactly this feature entails and how it works. I personally don't use tmux at all.

Because of that, I can not make any concrete judgement if this is definitely within scope or not, but I'm not against exploring it.

Though the priority is definitely not high for me, since I think this is a pretty niche feature especially since Alacritty does not aim to support tabs which probably are more useful here than windows.

Control mode is a text protocol that allows a program to provide its own interface to tmux, it is in no way a requirement to use tmux. Basically tmux provides persistence and another program provides the UI.

It means that if you are an iTerm2 user you can attach from your Mac to a remote tmux session using control mode and iTerm2 manages all the terminals and you get all the swish OS X and iTerm2 UI stuff that you like, but also have tmux's persistence and the option of attaching from elsewhere and using tmux's standard interface.

There are other uses but this is the most common (and what it was written for).

I don't really know how hard it is to implement or how well it actually works since I don't use OS X, but people seem to like it so I assume it works quite well.

I would guess it makes more sense for iTerm2 than many other terminals because I think iTerm2 provides a lot of "added value" features which I expect are nice to have whether you are using tmux or not, and probably don't work too well when tmux is drawing the terminals itself.

I'm not suggesting you add it, but that's what it is... :-)

Hello dear developers. I've done a small video to show, what the tmux control mode is and how the PoC implemented in terminator fork

The advantage of this approach, the state of existing panes and tabs is in the tmux. And the terminal emulator (any of them) just uses the text to render proper widgets. For example, iTerm2 launches another window by connecting to a remote host and finding an existing tmux session there.

I don't see why a terminal emulator would need any explicit support for this.

Because it is simply wonderful. You get rid of the ncurses interface and tmux doesn't hijack any of your keyboard shortcuts (most notably the readline ones), and you get a proper window manager to actually manage the tmux panes as windows.

And by connecting to remote tmux the same thing could be done: launch local terminal emulator with panes and tabs managed and stored in remote tmux.

Can this then be mixed? For instance, pane = alacritty window; split = tui tmux split? Since alacritty does not support all features tmux does, the scope might get difficult.

How hard would it be write something on top of alacritty without having this feature supported by alacritty itself. As in each split/pane will be a separate alacritty window.

I am guessing that this would not be a huge resource hog once we have multi-window support.

Something along the lines of https://github.com/alacritty/alacritty/issues/607#issuecomment-315202528

There's absolutely no reason why you wouldn't be able to connect to a single tmux backend from multiple Alacritty instances.

However there is absolutely no desire to implement features like tabs/splits/panes in Alacritty, if you want that just create multiple Alacritty windows from your WM.

And a terminal application itself shouldn't mess with opening or resizing Windows, so I highly doubt that will ever be supported either. This should be requested by the user when launching Alacritty, not the other way around.

Suggestion to close this and reopen, once multiple windows landed. Especially design concerns regarding speed and feature creep may be better evaluated then.

Multiple windows issue is now closed.

Multiple windows being closed is pretty much irrelevant to this issue. As stated in my last comment I don't see this issue playing well with Alacritty's goals.

I do all of my work in a remote machine over SSH and I find the iTerm2 tmux integration invaluable because I can open a new terminal window and it will continue to use the same SSH connection and even open the new terminal window to the same folder.

However there is absolutely no desire to implement features like tabs/splits/panes in Alacritty, if you want that just create multiple Alacritty windows from your WM.

I'm similarly not interested in tabs/splits/panes; just opening new windows that retain the same ssh connection / folder to make working on a remote machine feel like a native experience that integrates with my tiling window manager.

Is there a way to achieve this behavior without tmux control mode support in alacritty?

https://github.com/alacritty/alacritty/assets/2790092/1377c241-41a3-414b-9b7a-4a55df837fed