Add fine-grained mouse report configurability like iTerm2

[zsimic]

Description of the new feature/enhancement

First of all: congrats on the tmux support you have so far, it's pretty great already out of the box! Lots of things "just work" right away, including with mouse reporting:

• using the mouse wheel works great (with the usual/typical tmux copy-mode)
• mouse reporting works perfectly well in tools like vim
• I was able to even easily make my favorite tmux window navigation shortcut work with this in my settings:

{ "command": {"action": "sendInput", "input": "\u001b[1;3C" }, "keys": "alt+right" },
{ "command": {"action": "sendInput", "input": "\u001b[1;3D" }, "keys": "alt+left" },

Where it's not working well unfortunately is when trying to simply select some text while under tmux (ie: simply click+drag -> nothing happens). Mouse reporting also does not work outside of tools like vim (ie: click on a tmux pane or window -> nothing happens)

Usually with tmux, when mouse reporting is completely transferred to tmux, then one can switch panes/windows by clicking (but one does lose the click+drag usual text selection method in that case).

My favorite mode with tmux integration is something that latest iTerm2 does on macos: one can enable mouse reporting for tmux, but limit it to wheel events only. That way, I can:

• use click+drag to select text (as-if tmux wasn't running at all)
• use mouse wheel to trigger the copy-mode in tmux and scroll through tmux output history (this works perfectly well currently in WindowsTerminal!)

Proposed technical implementation details (optional)

Feature request: can you make it so that one can choose to pass through mouse wheel events only to tmux? Perhaps a new optional setting such as:

"mouseReporting": "enabled|disabled|wheelOnly"

[zadjii-msft]

As an immediate workaround, you can hold shift while in mouse mode to "escape" mouse mode, and force the terminal to handle the mouse instead. So that might let you get the best of both worlds while we work on this.

As far as the actual feature request - it seems reasonable, especially if there's prior art for us to use as a reference (in this case iTerm2).

[zsimic]

Yes, shift+drag does trigger forced-selection, but then it's stuck at the point where it started (just like shift+click to extend selection in general). That's a relatively ok workaround... very annoying to deal with the selection-extension thing, but manageable thanks to ESC key.

A "forced-selection" is my favorite way of selecting text (even while in tmux): much simpler / more direct than selecting from within tmux, and then trying to find a way to "send what was selected to the clipboard"...

iTerm2 added that very recently (it's not in their online docs yet). It's extremely convenient. I'll attach a small screenshot showing where it's at.

A corollary of this could be to make this configurable as well, for example:

• allow to key-bind mouse clicks as well
• have an action called selectRegion or something like that to represent click+drag text selection
• make copy action able to clear current selection optionally
• we'd be then able to use mouse clicks as well for other actions like paste :)

{ "command": { "action": "selectRegion", "extend": false }, "keys": "alt+left_click" },
{ "command": { "action": "selectRegion", "extend": true }, "keys": "shift+left_click" },
{ "command": { "action": "copy", "singleLine": false, "clearSelection": true }, "keys": "right_click" },
{ "command": "paste", "keys": "middle_click" },

[DennisGaida]

Since you gave me the idea to fix my ALT+cursor keys mappings, add these as well for horizontal panes:

  { "command": {"action": "sendInput", "input": "\u001b[1;3B" }, "keys": "alt+down" },
  { "command": {"action": "sendInput", "input": "\u001b[1;3A" }, "keys": "alt+up" }

[zsimic]

Yup, these ALT+arrow codes are pretty standard, would be cool also if they were in there by default indeed.

This is what I use in my tmux (alt+left/right to move to adjacent tmux window [not using up/down yet], alt+shift+arrows to move through panes, ctrl+shift+arrow to resize panes):

        // Alt + arrow keys
        { "command": {"action": "sendInput", "input": "\u001b[1;3A" }, "keys": "alt+up" },
        { "command": {"action": "sendInput", "input": "\u001b[1;3B" }, "keys": "alt+down" },
        { "command": {"action": "sendInput", "input": "\u001b[1;3C" }, "keys": "alt+right" },
        { "command": {"action": "sendInput", "input": "\u001b[1;3D" }, "keys": "alt+left" },

        // Shift + Alt + arrow keys
        { "command": {"action": "sendInput", "input": "\u001b[1;4A" }, "keys": "alt+shift+up" },
        { "command": {"action": "sendInput", "input": "\u001b[1;4B" }, "keys": "alt+shift+down" },
        { "command": {"action": "sendInput", "input": "\u001b[1;4C" }, "keys": "alt+shift+right" },
        { "command": {"action": "sendInput", "input": "\u001b[1;4D" }, "keys": "alt+shift+left" },

        // CTRL + Shift + arrow keys
        { "command": {"action": "sendInput", "input": "\u001b[1;6A" }, "keys": "ctrl+shift+up" },
        { "command": {"action": "sendInput", "input": "\u001b[1;6B" }, "keys": "ctrl+shift+down" },
        { "command": {"action": "sendInput", "input": "\u001b[1;6C" }, "keys": "ctrl+shift+right" },
        { "command": {"action": "sendInput", "input": "\u001b[1;6D" }, "keys": "ctrl+shift+left" },

Not sure where the spec is at, guessing here: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-PC-Style-Function-Keys

[DHowett]

Sorry, I'm confused. We support all modified keys, and they all generate the right input without custom bindings per the PC style function keys spec.

Now, the terminal app binds alt+arrows to pane navigation. You can unbind those, and you don't have to re-bind them to generate input (which is especially nice because sendInput bindings are inflexible in the face of alternate encodings/modes requested by apps)

[DHowett]

(We bind alt+shift+arrows for pane resize.)

[zsimic]

I just tried commenting out my specifics from ~/.tmux.conf (which I have here: https://gist.github.com/zsimic/03d4ac3cedf40a88f1d5):

#bind -n M-Up        select-pane -U
...
#bind -rn C-S-Up     resize-pane -U 2
...

Also removed all above keybindings from WindowsTerminal settings, to see what happens with defaults. Leaving it at default state, alt+shift + arrow keys does nothing in my case (nor does alt + arrow keys etc).

With the keybindings above (and my .tmux.conf), things work as expected in WindowsTerminal :)

[DHowett]

When you say you've removed them, you mean you've explicitly set them to unbound? The WT default settings (hold down Alt while clicking the Settings menu item) specify bindings for Alt+Arrows and Shift+Alt+Arrows. :smile:

[zsimic]

I removed them from my own settings.json, and restarted WT :) (and also completely closed/restarted tmux as well, to avoid any "lingering keybinds" that may have stayed from previous run)

Saw the defaults yes, and I see they have stuff like:

{ "command": { "action": "resizePane", "direction": "down" }, "keys": "alt+shift+down" },

That doesn't seem to resize tmux panes though (at least, not for me). Maybe it resizes WT's own panes? I'm using latest WT, enabled WSL2, and using ubuntu 20.04 from windows app store.

I start tmux within the WT + ubuntu session. tmux -V -> version 3.0a

[DHowett]

Yes, those bindings resize WT panes. If you want to pass them through to a connected application, you'll have to unbind them. Sorry about that. :smile:

[zsimic]

Ah makes sense now! That indeed is the case, I can do this instead:

        { "command": {"action": "unbound" }, "keys": "alt+right" },
        { "command": {"action": "unbound" }, "keys": "alt+left" },
        ...

Thanks! That's actually better than having to find/list the proper escape sequences!

[DHowett]

Alright, I think I understand this well enough to triage it and turn it into tasks. I'm precipitating it into the ask, "let me configure what parts of mouse reporting are enabled."

[DHowett]

(whoops: i selected the wrong quick action. ignore the closure!)