Tmux on windows

Skip to content. Sign in Sign up. Instantly share code, notes, and snippets. Last active Dec 20, Code Revisions 7 Stars Embed What would you like to do? Embed Embed this gist in your website. Share Copy sharable link for this gist. Learn more about clone URLs. Download ZIP. This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below.

To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters. I might give it a try to see if it's possible to create an MinGW build of tmux.

I'm an outside contributor of Windows Terminal so I know it's possible to have tmux on Windows and I'd personally love to see it happen. I expect the problems you will have will be with file descriptor passing, the other socket stuff should be possible to get working. Something like what we do for Cygwin where we just open the ttyname in the server might work, I don't know anything about Windows terminal APIs.

But outside MSYS2 it errors out:. Of course this would mean two extra threads for every pane. Doing this in a way that is concealed enough from tmux not to cause major disruption would need some care. I know that the server controls all the drawing of clients by manipulating the tty handle. How does server handle the output from shell? But there is no reason it couldn't do the same for window ptys and then one API could do both. The output from panes is handled in window.

There is no reason window. So if you provided an API with functions like the libevent ones used by tty. Then for most platforms this could be backed by libevent and on Windows it could deliver to a helper thread.

It would be fine if write always returned success - the flow control wouldn't work but we could live without that too. Funny that I thought there's no way you would want introduce extra threads, let along extra threads per pane since right now libevent use no thread at all.

So I stop exploring the this option. Now that you're OK with it, I'll give a try when I have the time. It would be better to use 1 thread for all panes, but I don't really mind how it works on Windows so long as it can be self-contained and doesn't make a mess of the rest of the codebase. Line in de4ac So when the callback is fired, tmux knows that it can write data to the file descriptor. So tty. And windows.

Is this correct? Pardon me for not really knowing Linux tty that well. I failed to find the connection point where the output of PTY is sent to the client. No extra steps need to be done, and this works out of the box. However, root keybindings — those which are listened globally, not in command mode — are still caught by the outer session only.

Another solution is to setup 2 individual prefixes, for example, C-b for a local session, while C-a for a remote one. With the configuration below, it means that pressing C-a locally would send default prefix C-b to the remote session. Found this solution here.

The better solution would be using same key table both on local and remote sessions — no separate prefixes or double pressing prefix — and turn off all keybindings and prefix handling in the outer session, when working with inner one. Credits and this Github issue. When that happens, the outer session shows the OFF visual indicator in the status line and changes the visual styling of status line to further stress that the session in in OFF mode.

Here is a Gist from my working tmux configuration , which I crafted recently only relevant pieces are included :. Basically, we setup F12 keybinding for the root key table. When pressed, we set prefix to None , switch current key table to off , then change the styles of status line, and force tmux to refresh the status line.

An extra step is taken to cancel the current pane copy mode, if it is present. As soon as we switched to off for the key table and turned off prefix handling, the outer session does not listen for any keystrokes at all. All keystrokes are passed to the inner session without being intercepted by the outer one.

Also, we configure a visual indicator for the status line, which shows on when current key table is off , and hides otherwise. To conclude, given this configuration, you can setup a single local session with 1 window with 2 panes that contains nested remote sessions to different hosts see image at the beginning of the post. In the previous example you might notice that the status line of the outer session is positioned at the top, where the inner session has its status line at the bottom.

That provides a nice visual distinction and does not make the status lines stack on top of each other.