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

Created on 24 Jun 2019  路  22Comments  路  Source: microsoft/terminal

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_

  • Fast scroll by holding down Alt while scrolling with mouse wheel #6182
  • Multiple sets of word delimiters for double-click selection #7173
  • xterm-style selection, paste on middle click, copy on mouse release #7646
Area-Input Area-Settings Area-TerminalControl Help Wanted Issue-Docs Issue-Scenario Product-Terminal

Most helpful comment

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

All 22 comments

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.

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

make .. scrolling work .. vim

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

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

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.

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.

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

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 )

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.

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:
ConHostMiddleClick
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.

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.

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

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

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

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

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

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.

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

Hi folks. Any update on this thread?

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

image

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

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.

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

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Wid-Mimosa picture Wid-Mimosa  路  3Comments

mrmlnc picture mrmlnc  路  3Comments

NickITGuy picture NickITGuy  路  3Comments

mdtauk picture mdtauk  路  3Comments

warpdesign picture warpdesign  路  3Comments