Feature Request: Mouse/Touch/Pointer Bindings (like middle-click paste, right-click context menu, etc.)

[carlos-zamora]

trafficstars

Summary of the new feature/enhancement

Expand settings to be able to define remappable mouse bindings. Arguably, different touch events should fall under this too. So let's just call this "pointer bindings" for now.

Proposed technical implementation details (optional)

Mouse bindings are a bit trickier than keybindings in that the mouse has a location where the event occurs. For example, right-clicking a tab should have a different effect on the terminal than right-clicking the terminal.

As a super early idea, consider this format:

"pointerbindings": [
{
  "device": "mouse",
  "event": "rightClick",
  "where": "tab",
  "command": "flyoutMenu"
},
{
  "device": "mouse",
  "event": "doubleClick",
  "where": "terminal",
  "command": "wordSelection"  
},
{
  "device": "touch",
  "event": "swipe",
  "where": "terminal",
  "command": "scroll"
}
]

We definitely need a spec for this because it'll be a bit hefty. We'll also need to update a decent amount of documentation (particularly settings schema) to be able to describe what combinations are acceptable (again, the JSON mentioned up here is just me rambling about a potential implementation.)

There may be overlap between some commands in keybindings. Be sure to think that through.

Mike notes:

we should go back and collect up all the threads we've said "this would be a good mouse bindings feature" below

---

spec draft

Mouse bindings

Abstract

We've had numerous requests to configure how the mouse behaves in the Terminal. The original behavior was a simple duplication of how conhost behaved: a right click will copy the a selection if there is one, or paste the clipboard if there isn't. Over time, we've accumulated a number of scenarios that we believe can all be addressed by allowing more fine-grained mouse binding support. However, upon further review, ultimately, we don't really need deep mouse binding support.

Scenarios

The following is a list of all the feature requests we've linked to mouse bindings in the past, grouped into categories of related requests:

Change how mouse multi-click selects

• [ ] #7173 Multiple sets of word delimiters for double-click selection
• [ ] #9881 Limit triple-click selection to command field only
• [ ] #6511 Multi-click selection granularity
• [ ] [#3196] Feature Request: Smart Double-click Selection (regeces?)

Change the action that L/M/R-mouse performs

• [ ] #7646 xterm-style selection, paste on middle click, copy on mouse release
• [ ] #10802 - VK_XBUTTON1/2, etc.
• [ ] #6250 - separate "Paste Clipboard" vs "Paste Selection" actions
• [x] #3337 - Add a right-click context menu

Other

These are smaller, independent features that could all have an individual setting (if needed)

• [ ] #11710 Request: Setting to disable zooming with ctrl+mousewheel
• [ ] #13598 Add option to configure URL clicking behavior
• [ ] #11906 Option to disable "Pinch to Zoom"
• [ ] #6182 Fast scroll by holding down Alt while scrolling with mouse wheel
• [ ] Block selection by default (without alt) (see mail thread "RE: How to disable line wrap selection in Terminal")
• [ ] #17610 Configure block select to use ctrl, not alt

Solution design

Following the above scenarios, solutions are proposed below:

Change how mouse multi-click selects

Across the requests here, we've got the following requests:

• double-click: selects a "word" between 2 same delimiters
• triple-click: selects an entire string separated by spaces
• 4-click: entire line

Currently, Ctrl+A will select the entire command/text input, however, triple clicking (mouse version of Select All selects the entire line (including the prompt). GIF shows selecting with mouse vs with keyboard: ... I would like the triple click action to align to the Ctrl+A selection method.

Could we maybe add shift double click to select using alternate word delimiters?

I was really thinking more of regex though, because it can be a good starting point for implementing more advanced features like type-specific smart highlighting and hyperlinking of terminal text, not just smart selection.

To boil this down, users want to be able to configure the behavior of double, triple, and quadruple clicks. The most common request is to change the delimiters for double-click selection. But users also want to be able to configure the delimiters to change on Shift/Alt/Ctrl clicks.

"mouse": {
    "clicks": {
        { "click": "double", "command": { "action": "expandSelection", "delimeters": " /\\()\"'-.,:;<>~!@#$%^&*|+=[]{}~?\u2502" } }
        { "click": "shift+double", "command": { "action": "expandSelection", "delimeters": " " } }
        { "click": "triple", "command": { "action": "expandSelection", "regex": "^.*$" } }
    }
}

Alternatively,

"mouse": {
    "doubleClick": " /\\()\"'-.,:;<>~!@#$%^&*|+=[]{}~?\u2502",
    "tripleClick": { "regex": "^.*$" }
}

[carlos-zamora]

A few things:

• Treat this as a megathread so feel free to share your ideas here 😁
• I'm a bit busy with Accessibility (TOP PRIORITY) at the moment so if anybody wants to start working on this, just let me know.

[philippeller]

Probably related, make for example scrolling work when using vim etc....used to work fine for example in WSL terminal

[DHowett-MSFT]

make .. scrolling work .. vim

That is not related. That is #376 then #545.

[schorrm]

Can I pile on here -- can we get two finger scrolling on the mousepad?

[cerebrate]

A small point that's probably obvious, but just to make sure it's said, can we make sure the default is and the defaults are to pass through mouse events within the terminal to the underlying VT, per #545?

Customizability I like, but not as much as not breaking anything that would otherwise work. If someone's using, for example, tmux mouse support in conhost, they shouldn't have to grovel through the options to figure out why it doesn't work in Terminal.

[zadjii-msft]

Though it's also being discussed in #524, I want to make sure it's tracked here that some people might not want copy-on-select. So that needs to somehow be included in these bindings. Though, that might make sense as a different setting, since I'm not sure if there are any other "onSelect" actions that would possibly make sense.

[vyevdokimov]

Add something like "lines to scroll" option - in some cases scroll is too fast in terminal using touchpad.

[MattBianco]

Top prio for me would be a way to bind "paste" to "middle-click" (clicking the mouse wheel) like in standard X11. See also #1612 ( and #524 )

[ts252]

I've not contributed to this project before, but I'd love to work on this.

Secretly, my motivation is to get middle-button pasting working: I see from these issues that the plan is to do that as part of a more general solution. All the better.

Just as a starting point for discussion: could we narrow the scope of pointerBindings to cover only those commands that can currently appear in keyBindings? i.e. just covering where: "terminal" for now. Would anyone be interested in my tackling it this way?

I've just put up a fork that simply does middle-button pasting under the control of a new global setting "middleButtonPaste". It works great for me but straight away you can see the lack of expressive power in the settings - there's no way to tell it what to do with the right button now, for instance.

[carlos-zamora]

Just as a starting point for discussion: could we narrow the scope of pointerBindings to cover only those commands that can currently appear in keyBindings? i.e. just covering where: "terminal" for now. Would anyone be interested in my tackling it this way?

That seems like a fairly reasonable scope. We would need a spec first, though, since this is a fairly sizeable feature. If you/anyone is interested in working on it, you can find a spec template here. Just fill it out and submit a PR. We can iterate on that before actually implementing it. Feel free to take a look at other spec-related PRs to get an idea of what the process looks like.

Secretly, my motivation is to get middle-button pasting working: I see from these issues that the plan is to do that as part of a more general solution. All the better.

I've just put up a fork that simply does middle-button pasting under the control of a new global setting "middleButtonPaste". It works great for me but straight away you can see the lack of expressive power in the settings - there's no way to tell it what to do with the right button now, for instance.

ConHost does this on a middle click: So, some people expect a middle click to do that. I think it just makes more sense to be able to bind middle click to whatever the user wants (what the default is is another story haha).

Expanding on that, (1) users should be able to bind other buttons on their mouse/stylus and (2) what should they actually be able to bind to? All keybindings make sense to be accepted as pointer bindings, at least to start. That's all stuff that should come up in the spec.

[SelfDrivingCarp]

I would love this. Middle-click paste would be good but disabling right-click paste would be wonderful.

I'm mostly working on a laptop that has a touchpad that doesn't have distinct buttons: when you click it senses if you're touching on the left or right side of a middle line. It's common that my hand isn't quite in the right position, I mean to left-click drag to select some text and suddenly the paste buffer barfs all over my vim :(.

I'm probably not the only person in this position and it might be important for people who have genuine mobility issues instead of just being impatient and clumsy, like myself.

[ts252]

Having read a couple of examples, I'm starting work on a spec.

[jasonnet]

Having read a couple of examples, I'm starting work on a spec.

That's great. Is this spec available for review?

[davidchisnall]

The current default of right-click to paste is problematic because it prevents using right-click to bring up a context menu. In every other terminal I use, right clicking on a link pops up a context menu that includes opening or copying the link as an option. I just accidentally pasted 20 lines into WT as a result of expecting the same behaviour (but I really do want a mouse button that I can use to paste!).

[pshem]

Any updates on disabling right click paste? It's really annoying

[zadjii-msft]

If we had anything to share, it'd be posted in this thread 😉 As you can see, this is in the 2.0 milestone currently, so we're hoping to get to it this year sometime.

[davidchisnall]

Thanks. I keep right-clicking on URLs to select 'copy link' or 'open link' from the context menu, forgetting which terminal I'm using, and paste a load of random stuff into my terminal...

[arsdever]

Hi folks. Any update on this thread?

[zadjii-msft]

Nope, when there's something to share, we'll be sure to bump the thread. Until then, the Subscribe button

is a good way to follow this thread for updates without pinging everyone else one the thread 😉

[mangelozzi]

If we had anything to share, it'd be posted in this thread 😉 As you can see, this is in the 2.0 milestone currently, so we're hoping to get to it this year sometime.

To me a lot of the 2.0 features were quite flashy. Maybe consider what do people really need? Foundational features like not accidentally sending commands on right click (surely this is a quick win?), being able to see the text (e.g. when white cursor on white background), bold text, and italic text, fallback glphs for block chars. Would be sweet if we could vote.

[yulei900609]

i need middle-click paste very much, hope this can be done soon.

[albgus]

Imo the best option would be to implement a distinct selection buffer that is mapped to the Middle mouse button, as is commonly found in Linux distros. This buffer would obviously need to be specific to the Terminal application and would "copy" things as soon as they're selected in the terminal. This would also free up right click to open a context menu which could include Copy and Paste options to interact with the system-wide copy-paste buffer.

[gregory-seidman]

Imo the best option would be to implement a distinct selection buffer that is mapped to the Middle mouse button, as is commonly found in Linux distros. This buffer would obviously need to be specific to the Terminal application and would "copy" things as soon as they're selected in the terminal. This would also free up right click to open a context menu which could include Copy and Paste options to interact with the system-wide copy-paste buffer.

Strong disagree. An app-specific clipboard flies in the face of the purpose of copy and paste, i.e. inter-app communication. Let's not reinvent the PRIMARY and CLIPBOARD and similar X11 warts. There is and should be a single, system-wide clipboard.

[davidchisnall]

Strong disagree. An app-specific clipboard flies in the face of the purpose of copy and paste, i.e. inter-app communication. Let's not reinvent the PRIMARY and CLIPBOARD and similar X11 warts. There is and should be a single, system-wide clipboard.

I would agree in general but I feel that a terminal is a special case because it runs a large number of other programs inside it. The vast majority of the things I copy in the terminal, I also paste into the terminal. In X11 terminals, I've found it very useful to have the Vim copy buffer, the PRIMARY buffer that I never use in things other than terminals, and the clipboard that I use for cross-application copy-and-paste. Beinf able to select something in one terminal and paste it in another without destroying the contents of my clipboard is something that I miss on Windows.

I don't believe this is something that everyone would want and it is probably something that should be off by default, but it is something tha tI personally would use and be very happy to see.

[TBBle]

This issue should probably remain focussed on implementing the pointer bindings themselves, and bindings for the existing pointer operations that are currently hard-coded.

New features, such as "copy to/paste from local buffer" are interesting as use-cases for this feature, but I would not expect any new features that replace existing features (like changing existing click behaviours) to happen until they can be exposed as bindings and hence enabled by those users who want them without changing the default mouse interaction we have now.

[getify]

I'm not sure what changed (windows, terminal, etc) lately, but in the last couple of weeks I've noticed this problem with ctrl+mousescroll doing unintentional zooming get MUCH worse... I'm on a Microsoft Surface Laptop 4 with Windows 10. My touchpad scrolling habits (with momentum), and pressing ctrl (to do some hotkey combo) isn't a problem in any other app (chrome, sublime, etc), but in the terminal, my font size grows or shrinks nearly every time I interact with the window.

It's so bad that I am thinking about stopping using Windows Terminal until this is addressed.

Either disable doing this at all, or give us the option to disable it. This has become a deal breaker for the Terminal app.

RE: #11710 #11906 #3990

[ChrisHeerschap]

I'm 100% with @getify on this. WT is nice but the inability to disable the ctrl-scroll zoom is really annoying and I was wondering the same about it becoming much more sensitive. Dare to touch the mousepad around the same time you've pressed CTRL and the font goes subatomic.

[zadjii-msft]

in the last couple of weeks

Hmm. Judging by https://github.com/microsoft/terminal/releases, that wouldn't be the recent servicing releases, that would probably be Preview v1.12.2922.0/ Stable v1.11.2921.0. If this has a root cause in the Terminal, then I'd suspect the point of regression being #10051, which first shipped in Preview v1.11.2421.0. If someone's hitting the overly sensitive trackpad thing and wouldn't mind manually installing https://github.com/microsoft/terminal/releases/tag/v1.11.2421.0 and comparing with https://github.com/microsoft/terminal/releases/tag/v1.10.1933.0, we might be able to check if this is a Terminal-side regression.

If it is, then I'd go ahead and promote that regression up to its own bug to get fixed in 1.13. Otherwise, the best course of action would be to draft the spec for this enough that we're confident on the syntax for "disable ctrl+wheel zooming / disable pinch zooming", and then try to ship just that element of the feature. That would of course take a lot longer. I'm reluctant to add a one-off setting for disabling those that we're going to replace in the near future anyways - if anything it would be something silly like experimental.disableFontZooming that's obviously going to be removed

[getify]

I don't recall having Preview or Stable installed, but I have v1.11.3471.0 installed currently, and I've been seeing this extra sensitivity lately (including in this version). Are you asking me to downgrade from 11.3471 to 11.2421 or to 10.1933?

[my-vegetable-has-exploded]

Is this issue still in developing？ I don't see relative setting in docs. Thanks