starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Add fine-grained mouse report configurability like iTerm2 #11969

New Issue
Open
opened 2026-01-31 03:02:47 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 03:02:47 +00:00
Owner
Copy Link

Originally created by @zsimic on GitHub (Jan 5, 2021).

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"
Originally created by @zsimic on GitHub (Jan 5, 2021). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # 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" ```
claunia added the Issue-FeatureArea-SettingsProduct-TerminalArea-TerminalControl labels 2026-01-31 03:02:47 +00:00
claunia commented 2026-01-31 03:02:48 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 5, 2021):

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).

@zadjii-msft commented on GitHub (Jan 5, 2021): As an immediate workaround, you can hold <kbd>shift</kbd> 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).
claunia commented 2026-01-31 03:02:48 +00:00
Author
Owner
Copy Link

@zsimic commented on GitHub (Jan 5, 2021):

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" },

wheel-only

@zsimic commented on GitHub (Jan 5, 2021): 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" }, ``` ![wheel-only](https://user-images.githubusercontent.com/747197/103710959-22ddfa80-4f6b-11eb-8ac7-ce05d47bc6ef.png)
claunia commented 2026-01-31 03:02:48 +00:00
Author
Owner
Copy Link

@DennisGaida commented on GitHub (Jan 6, 2021):

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" }
@DennisGaida commented on GitHub (Jan 6, 2021): 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" } ```
claunia commented 2026-01-31 03:02:49 +00:00
Author
Owner
Copy Link

@zsimic commented on GitHub (Jan 6, 2021):

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

@zsimic commented on GitHub (Jan 6, 2021): 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
claunia commented 2026-01-31 03:02:49 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 6, 2021):

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 commented on GitHub (Jan 6, 2021): 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)
claunia commented 2026-01-31 03:02:49 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 6, 2021):

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

@DHowett commented on GitHub (Jan 6, 2021): (We bind alt+shift+arrows for pane resize.)
claunia commented 2026-01-31 03:02:50 +00:00
Author
Owner
Copy Link

@zsimic commented on GitHub (Jan 6, 2021):

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 :)

@zsimic commented on GitHub (Jan 6, 2021): 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 :)
claunia commented 2026-01-31 03:02:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 6, 2021):

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. 😄

@DHowett commented on GitHub (Jan 6, 2021): 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:
claunia commented 2026-01-31 03:02:50 +00:00
Author
Owner
Copy Link

@zsimic commented on GitHub (Jan 6, 2021):

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

@zsimic commented on GitHub (Jan 6, 2021): 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
claunia commented 2026-01-31 03:02:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 6, 2021):

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. 😄

@DHowett commented on GitHub (Jan 6, 2021): 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:
claunia commented 2026-01-31 03:02:51 +00:00
Author
Owner
Copy Link

@zsimic commented on GitHub (Jan 6, 2021):

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!

@zsimic commented on GitHub (Jan 6, 2021): 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!
claunia commented 2026-01-31 03:02:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 28, 2021):

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 commented on GitHub (Jan 28, 2021): 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."
claunia commented 2026-01-31 03:02:51 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 28, 2021):

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

@DHowett commented on GitHub (Jan 28, 2021): (whoops: i selected the wrong quick action. ignore the closure!)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Area-TerminalControl Issue-Feature Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11969
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?