Mouse mode in tmux

[hfaran]

The following is my conf file for tmux (I use version 2.1).

$ cat ~/.tmux.conf
# Mouse support
set -g mouse  on

set-window-option -g xterm-keys on
setw -g aggressive-resize on

# List of plugins
# Supports `github_username/repo` or full git repo URLs
set -g @tpm_plugins '              \
  tmux-plugins/tpm                 \
  tmux-plugins/tmux-resurrect      \
  tmux-plugins/tmux-continuum      \
'

# Initializes TMUX plugin manager.
# Keep this line at the very bottom of tmux.conf.
run-shell '~/.tmux/plugins/tpm/tpm'

Should I expect the mouse to work within tmux at this stage? It does not seem be.

[fpqc]

bash.exe is currently a Windows console application (runs in conhost like Powershell and cmd). This is a problem currently with on the one hand conhost not sending the right ANSI escape sequences for mouse input to the running linux terminal app, and otoh, bash.exe not listening for them.

There's kind of a hack, but it does work if you want to use tmux on WSL before the major improvements to conhost and the bash.exe wrapper come along. First, install Xming on windows, then sudo apt-get install rxvt-unicode-256color in bash.

See Edit for a better way

First, install a script called urxvtdc (search online for it, wget it, and sudo install to /usr/local/bin, or if you know how to use curl (I don't), use that to install directly from the internet)

Then, with Xming running, run the command:

(DISPLAY=:0 urxvtdc &)

(urxvtdc is a shellscript running rxvt-unicode client that also starts the daemon if needed).

This will run rxvt-unicode as an X application in xming, detached from the initial terminal from which you opened it (although if you do close all bash.exe terminals, it will kill rxvt (even if you initiate it as a non-child process by putting it in parentheses, because WSL kills the LXSS session if there is no copy of bash.exe running in conhost) , and then you can run tmux inside there with full mouse and color support.

You can use this to launch several copies of urxvt from a single bash.exe window (but do not close the original bash.exe window.

I tried this right now with gnome-terminal for laughs, and it does not work (I think because GTK and GNOME use dbus, which doesn't work on WSL right now).

Also, if you are okay with leaving at least one bash.exe window open running in conhost (since it's Windows 10, just put it on some secondary virtual desktop and forget about it), you can directly open your urxvt terminal from the Run dialog with:

bash.exe ~ -c "(DISPLAY=:0 urxvtdc &)"

urxvt is kind of ugly by default, but it can be configured for Xming using ~/.Xdefaults in your WSL home directory. There is a nice solarized profile on github that you can keep an eye out for.

Here is me running tmux locally in urxvt on WSL:

http://i.imgur.com/JLECvTI.png

and here is me running Weechat in remote tmux over ssh running in urxvt on WSL

http://i.imgur.com/y4sxk8W.png

It would be cool if Microsoft directly supported some way to launch X apps directly (Windows Subsystem for POSIX had an X server, although it was iirc not complete), instead of having to run them by passing arguments to a console application. I can imagine that someone could do some kind of hack of the bash.exe wrapper to run silently or hide it in the system tray (sort of like VirtualBox's headless tray manager).

Ideally though, you wouldn't have to run urxvt at all, but it seems like the major console upgrades for Windows are not going to make it into the Anniversary release.

Edit: Solution to run urxvtd in the background

Make a shellscript in the Linux side called runurxvtd:

#!/bin/bash
urxvtd -q -o -f
$SHELL

and sudo install runurxvtd /usr/local/bin/unurxvtd

Then copy run.exe into some location in your Windows PATH
http://www.straightrunning.com/projectrun/run-x64.zip

To start urxvtd silently in the background in Windows (for example, on startup), run the command
run bash.exe -c runurxvtd

Then whenever you want to want to run urxvt, just run
bash.exe ~ -c "(DISPLAY=:0 urxvtc &)"

which will open in XMing with no problems.

Run.exe can also be used to start sshd silently.

[hfaran]

Thanks for the explanation @fpqc

[zadjii-msft]

To speak to the crux of the issue: We'd love to support mouse mode in conhost, but unfortunately that wasn't able to make it for this release. It's definitely high on the backlog for the next though :)

[fpqc]

@zadjii-msft well, could you get it into this release keeping the lxsession online while X servers are running without leaving a conhost window open?

[wangxu94]

Thanks for the guide @fpqc. Just one thing, there seems to be a typo in your edit.
sudo install runurxvtd /usr/local/bin/unurxvtd should be sudo install runurxvtd /usr/local/bin/runurxvtd

[Manouchehri]

@fpqc: After opening urxvtc once, I can't seem to open it again until I restart urxvtd.

/mnt/c/Users/Dave/Desktop > urxvtc
/mnt/c/Users/Dave/Desktop > urxvtc
urxvt: protocol error while reading pty/tty fds from helper process, aborting.

[stevenengler]

@Manouchehri Did you figure this out? I cannot seem to run urxvtc even the first time, always getting the same error as you.

[fpqc]

@stevenengler you have to run urxvtd -q -o -f in a terminal first, then run DISPLAY=:0 urxvtc . There are tricks to hide the console used to launch urxvtd using the OSS run utility from straightrunning (the guy who does xming).

Once you have it set up, do

run.exe bash.exe -c "urxvtd -q -o -f; bash" to launch the daemon hidden, then launch urxvtc with

bash.exe -c "(DISPLAY=:0 urxvtc &)"

[stevenengler]

@fpqc Thanks, I believe that was exactly what I was doing earlier (well using export DISPLAY=:0 first), but now after leaving it for a while and restarting my computer, it seems to be working.

Just as a summary, in Windows I installed the VcXsrv server, and in the Linux subsystem I installed sudo apt-get install rxvt-unicode-256color. The commands you posted urxvtd -q -o -f and DISPLAY=:0 urxvtc now seem to work properly and the X window appears.

Thanks again for your write-up.

[fpqc]

export only works for that instance of bash, and if you had put it in .bashrc, it only gets loaded when bash is in interactive mode.

[Mxbonn]

Any updates as when to expect this implemented?

[fpqc]

@Mxbonn @bitcrazed has not given too much detail on the status of planned console improvements. In the mean time, try @mintty 's wsltty

[zadjii-msft]

So yea I think this has been in insiders for a while now, can someone confirm that?

[fpqc]

@zadjii-msft Mouse mode works in both tmux and weechat as of 14965 here.

[carlpaten]

I'm in the Slow ring and this works perfectly.

[zadjii-msft]

Fantastic, I'll close this then.

[Trolldemorted]

@zadjii-msft unfortunately the problem still exists if you start the WSL shell in the new windows terminal.

Could you address that too? Will that also fix tmux' mouse mode on linux remote hosts when using ssh in powershell?

[zadjii-msft]

@Trolldemorted That's correct. The new Terminal requires microsoft/terminal#376 to be done to add mouse support to conpty, then microsoft/terminal#545 will rtack adding support for mouse input to the terminal itself.

What do you mean about

tmux' mouse mode on linux remote hosts when using ssh in powershell?

Using mouse mode with conhost as the terminal should work perfectly fine. Are you using the inbox ssh.exe? I know there are a bunch of bugs with that. If it's not working, could you file an issue on them?

[Trolldemorted]

That's nice to hear!

If I use powershell, not matter if it is in the new terminal or just the plain old powershell (I guess that is hosted by conhost?), after sshing onto a remote, tmux mouse mode does not work (using the openssh client in C:\Windows\System32).

Should that work? Where should I file the bug report? Is it a powershell or a conhost bug? I assume conhost because left clicks only select something in the window, and don't appear to be passed to the shell?

[dragon788]

@Trolldemorted if you go into the properties and disable QuickEdit mode does that allow the clicks to pass through?

[Trolldemorted]

I just checked in the normal powershell, with disabled QuickEdit it does not work either. Not being able to easily select things would also be a pity, to be honest :(

[zadjii-msft]

@Trolldemorted Yea, that's definitely an OpenSSH bug. You can search for an issue and file one if it's not already tracked here: PowerShell/Win32-OpenSSH

[Trolldemorted]

Thanks for the link to the correct repository!

PowerShell/Win32-OpenSSH#1158
Looks like mouse events are completely unsupported right now, let's hope they find the time to address that someday.