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

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
[Feature Request: Smart Double-click Selection (regeces?) #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
#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": "^.*$" }
}

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?

Here is my suggestion.

The mouse has few buttons, so we can simplify the configuration.
We don't need double middle-click or triple right-click. 99.99% of users do not use such complex click combinations, so they should not be implemented.
We can assume that left-clicks are dedicated to selections.
Supporting only Shift key as modifier can simplify the configuration.

First, implement the following settings as a priority.

"mouse": {
    "selection": {
      "double": "selectBetweenSpaces",
      "triple": "selectBetweenSymbols",
      "quad": "selectLine",
      "shift+double": "selectBetweenSpaces"
      // no "shift+triple", "shift+quad" for simplicity
    },
    "action": {
      "middle": "paste",
      "right": "openContextMenu",
      "shift+middle": "pasteSelection",
      "shift+right": { "action": "copy", "singleLine": false }
      // also, no "alt+middle", "ctrl+right"... for simplicity
    }
}

Then, extend the functionality as shown below.

"mouse": {
    "selection": {
      "double": "selectBetweenSpaces",
      "triple": { "action": "select", "delimiters": " /\\()'-.,:;<>~!@#$%^&*|+=[]{}~?\u2502" },
      "quad": "selectLine",
      "shift+double": { "action": "select", "regex": "^.*$" }
      // no "shift+triple", "shift+quad" for simplicity
    },
    "action": {
      "middle": "paste",
      "right": "openContextMenu",
      "shift+middle": "pasteSelection",
      "shift+right": { "action": "copy", "singleLine": false }
      // also, no "alt+middle", "ctrl+right"... for simplicity
    }
}

edit: "shift+left", "alt+middle", "ctrl+right" may be added later, but only for config file, not on settings UI.

The mouse has few buttons, so we can simplify the configuration.

Some mouse such as the Razer Naga has 17 buttons. A lot of mouse have 5 (thumb buttons), or even 7 when the left/right thumb buttons are considered different.

We don't need double middle-click or triple right-click. 99.99% of users do not use such complex click combinations, so they should not be implemented.

We can assume that left-clicks are dedicated to selections.

Supporting only Shift key as modifier can simplify the configuration.

IMHO this is over-simplification based on personal preference (a "quad-click" but not "ctrl-click"? wut?). This eliminates so many possibilities that one could even question the point of fixing the issue. After all, "99.95%" of users won't even bother with rebinding.

This proposal is also contrary to why the issue hasn't been closed yet. The MS team wants to support as many usages as possible, to the point of being frozen in indecision. This proposal would support none of them but the most basic ones. And it will most certainly leads to more feature requests for the missing options.

Last, this also similar to one of the biggest complaints about modern UX, where customization is limited for the sake of simplification (e.g. see Firefox, or Gnome, or Windows vs Linux).
And as they say, common thing should be simple, but advanced things should be possible. Potentially, the Terminal UI could limit the choices (within reason) to keep things simple for "normal users", but the configuration file should not and should allow tweaking by the "advanced users".

Some mouse such as the Razer Naga has 17 buttons.

Well then, what about touchscreen, pen tablet, touchpad, etc.? If we try to support every device, there will be no end. These devices have their own driver software, which should handle such configurations.

This proposal would support none of them but the most basic ones.

What we need is gradual implementation, not all-in-one super ultimate HID binding which will never be implemented. My suggestion can solve most issues and can be expanded later if needed.

... the configuration file should not and should allow tweaking by the "advanced users".

We can add "ctrl+click" or "alt+middle" to config file later, but not now for the reasons mentioned above.

Sorry, but all I need is a simple middle-click to paste, and it looks like I'll have to wait another 5 years without simplification.

sweth

Well then, what about touchscreen, pen tablet, touchpad, etc.? If we try to support every device, there will be no end.

There is no need to go from one extreme to the other. You affirmed that mice has few buttons. I'm saying that's not quite true. Supporting more buttons is trivial compared to supporting different device types.

These devices have their own driver software, which should handle such configurations.

If this is all it takes, then feel free to use such software to remap right-click to the middle button.

We can add [...] to config file later

Your proposal only mention the easy config. How do you see your format supporting more buttons/more modifiers/more devices/...? To clarify what I mentioned before, the reason the ticket stalled is not necessarily because the MS team wants to support everything at once, or because it's complicated to implement, but because they want a schema that can be easily extended to support advanced scenarios. If your solution is to just start with a simple schema and redo it later for the advanced scenario, then the MS teams already said they were not interested in doing so.

Sorry, but all I need is a simple middle-click to paste

This ticket is not just about you.

Unrelated: sweth, adrian-dinu, no need to promote the post from inko94, it's a copy/paste of the top post. That and the activity of that account indicate it's very likely a fake account trying to build a history

Nahor

Nahor

Not every mouse driver supports per app mouse binding. And also, #1553 (comment)

#1553 (comment)
MS teams are open for suggestion about breadth of configure about the mouse.

There are many, many comments requesting similar simple middle click paste.
#1553 (comment) #1553 (comment) #1553 (comment) and so on...
Sure this ticket is not just about me. But I believe I'm allowed to share my suggestions as well, aren't I?

I guess when I followed this I imagined it just being a something simple you could add to the existing 'keys' section of the 'actions'.

https://learn.microsoft.com/en-us/windows/terminal/customize-settings/actions#modifier-keys

I would assume you have a bunch of names like this Assume you have a bunch of names like below, where the names follow a pattern like mouse_BUTTONNAME_EVENTTYPE.

mouse_left_click
mouse_left_doubleclick
mouse_right_click
mouse_middle_click

Button name could like left, right, middle, button1, ..., buttonNN and any other obscure names that might be added later.

The event names could start by following similar names as used in WinForms.

So click, doubleclick, mousedown, mouseup, and so on. Possibly only starting with click and doubleclick and adding support for some kind of touchpads, other devices, and the less common events later.

https://learn.microsoft.com/en-us/dotnet/desktop/winforms/input-mouse/events?view=netdesktop-9.0#mouse-events

Anyway, you would then be able to have a configuration like this.

{
    "actions": 
    [
        {
            "command": "paste",
            "keys": "mouse_middle_click"
        },
        {
            "command": "showContextMenu",
            "keys": "mouse_right_click"
        },
        {
            "command": "openAbout",
            "keys": "shift+mouse_right_click"
        },
        {
            "command":
            {
                "action": "copy",
                "singleLine": false
            },
            "keys": "ctrl+c"
        }
    ],
    ...
}

Perhaps I am missing some complications, but I am not sure why you would want a new 'mouse' or 'pointerbindings' section in the configuration.

I guess when I followed this I imagined it just being a something simple you could add to the existing 'keys' section of the 'actions'.

Same idea as mine.

* mouse_left_click
* mouse_left_doubleclick
* mouse_right_click
* mouse_middle_click

I would remove the mouse_ prefix to reduce the verbosity, or make it optional, since "left_click" pretty much always implies a mouse event [...]

Button name could like [...] button1, ..., buttonNN and any other obscure names that might be added later.

[...] but for those, keeping the mouse_ prefix would be useful since a "button" can be anything.
I would however make button1/2/3 be aliases for left/right/middle, or only supports "button4" and up. I think this is more common.

Anyway, you would then be able to have a configuration like this.
[...]

And for future extensions, the keys values, currently JSON strings, could become JSON objects so one can add more details:

{
   "command": ...
   "keys":
   {
       /* aka "shift+alt+mouse_button4_tripleclick" but without requiring hard coding a key name in the code,
          i.e. extensible to any button and any number of clicks */
       "deviceType": "mouse"      /* or "keyboard", "touchpad", ... for other scenarios */
       "button": 4                /* also accepts the usual suspects: "left", "right", "middle" */
                                  /* alternatively, `"key": 4` if we want to standardized */
                                  /* the main action button/key across the device types */
       "modifiers": "shift+alt"   /* or maybe an array to avoid the extra parsing of the value: [ "shift", "alt" ] */
       "clickCount": 3            /* also accepts the usual suspects: "double", "triple" */
   }
}

Indeed, I don't need double middle-click or triple right-click. I only use multiple clicks with the left mouse button

I do wonder how things would behave for left-handed people who decide to revert the order of the buttons. I have at least one left-handed colleague who uses his mouse left of the keyboard, with the left mouse button acting as a regular right-mouse, and the right acting as left. But maybe the drivers will generate events/callbacks/whatever where whatever the user wants to be the left button is always called the left button

I have added below a screenshot (unfortunately in French) of what I get with : Win+I => Devices => Mouse. There is an option to choose if you want the main button to be the left or the right one

So... Several other requests were made for a simple way to disable right-click paste and they all get closed as "dupes" of this mega six years old thread on how to do the perfect thing to release in 2999.

How about some KISS here? Why the over complication when we could have had some simple wins by now?

Some useful, even if imperfect, functionally beats the C*** out of having exactly ZERO percent of a perfect implementation 6 (SIX!) years later, with NO date in sight...

useful, even if imperfect

FWIW, you can disable right-click paste today by turning on the right-click context menu instead. It's useful, it is maybe imperfect, but it has existed for the better part of the past three years.

~6 years later... any news?

Navigation Menu

Repository navigation

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

Summary of the new feature/enhancement

Proposed technical implementation details (optional)

Mike notes:

spec draft

Mouse bindings

Abstract

Scenarios

Change how mouse multi-click selects

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

Other

Solution design

Change how mouse multi-click selects

78 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary of the new feature/enhancement

Proposed technical implementation details (optional)

Mike notes:

spec draft

Mouse bindings

Abstract

Scenarios

Change how mouse multi-click selects

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

Other

Solution design

Change how mouse multi-click selects

Activity

carlos-zamora commented on Jun 24, 2019

philippeller commented on Jun 25, 2019

DHowett-MSFT commented on Jun 25, 2019

schorrm commented on Jun 27, 2019

78 remaining items

inko94 commented on Mar 2, 2025

dofuuz commented on Mar 3, 2025

Nahor commented on Mar 3, 2025

dofuuz commented on Mar 4, 2025

Nahor commented on Mar 4, 2025

dofuuz commented on Mar 4, 2025

zoredache commented on Mar 4, 2025

Nahor commented on Mar 4, 2025

jypeter commented on Mar 5, 2025

fmad commented on Oct 22, 2025

DHowett commented on Oct 22, 2025

ajm19826 commented on Feb 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions