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

@DHowett-MSFT commented on GitHub (Jun 26, 2019):

make .. scrolling work .. vim

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

@DHowett-MSFT commented on GitHub (Jun 26, 2019): > make .. scrolling work .. vim That is not related. That is #376 then #545.

claunia commented

@schorrm commented on GitHub (Jun 27, 2019):

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

@schorrm commented on GitHub (Jun 27, 2019): Can I pile on here -- can we get two finger scrolling on the mousepad?

claunia commented

@cerebrate commented on GitHub (Jun 29, 2019):

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.

@cerebrate commented on GitHub (Jun 29, 2019): 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.

claunia commented

@zadjii-msft commented on GitHub (Jul 2, 2019):

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.

@zadjii-msft commented on GitHub (Jul 2, 2019): 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.

claunia commented

@vyevdokimov commented on GitHub (Oct 19, 2019):

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

@vyevdokimov commented on GitHub (Oct 19, 2019): Add something like "lines to scroll" option - in some cases scroll is too fast in terminal using touchpad.

claunia commented

@MattBianco commented on GitHub (Jan 23, 2020):

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 )

@MattBianco commented on GitHub (Jan 23, 2020): 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 )

claunia commented

@ts252 commented on GitHub (Jan 27, 2020):

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.

@ts252 commented on GitHub (Jan 27, 2020): 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.

claunia commented

@carlos-zamora commented on GitHub (Jan 28, 2020):

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.

@carlos-zamora commented on GitHub (Jan 28, 2020): > 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](https://github.com/microsoft/terminal/blob/master/doc/specs/spec-template.md). 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](https://user-images.githubusercontent.com/11050425/73305126-57c7c600-41ce-11ea-87ff-3a43516cef85.gif) 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.

claunia commented

@SelfDrivingCarp commented on GitHub (Jan 30, 2020):

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.

@SelfDrivingCarp commented on GitHub (Jan 30, 2020): 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.

claunia commented

@ts252 commented on GitHub (Jan 30, 2020):

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

@ts252 commented on GitHub (Jan 30, 2020): Having read a couple of examples, I'm starting work on a spec.

claunia commented

@jasonnet commented on GitHub (May 25, 2020):

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

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

@jasonnet commented on GitHub (May 25, 2020): > > > Having read a couple of examples, I'm starting work on a spec. That's great. Is this spec available for review?

claunia commented

@davidchisnall commented on GitHub (May 29, 2020):

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

@davidchisnall commented on GitHub (May 29, 2020): 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!).

claunia commented

@pshem commented on GitHub (Jun 26, 2020):

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

@pshem commented on GitHub (Jun 26, 2020): Any updates on disabling right click paste? It's really annoying

claunia commented

@zadjii-msft commented on GitHub (Jun 26, 2020):

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.

@zadjii-msft commented on GitHub (Jun 26, 2020): 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.

claunia commented

@davidchisnall commented on GitHub (Jun 26, 2020):

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

@davidchisnall commented on GitHub (Jun 26, 2020): 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...

claunia commented

@arsdever commented on GitHub (Aug 8, 2020):

Hi folks. Any update on this thread?

@arsdever commented on GitHub (Aug 8, 2020): Hi folks. Any update on this thread?

claunia commented

@zadjii-msft commented on GitHub (Aug 10, 2020):

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 😉

@zadjii-msft commented on GitHub (Aug 10, 2020): Nope, when there's something to share, we'll be sure to bump the thread. Until then, the Subscribe button ![image](https://user-images.githubusercontent.com/18356694/89787751-a215f200-dae3-11ea-9461-722fe9e1e1f1.png) is a good way to follow this thread for updates without pinging everyone else one the thread 😉

claunia commented

@mangelozzi commented on GitHub (Sep 7, 2020):

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.

@mangelozzi commented on GitHub (Sep 7, 2020): > 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.

claunia commented

@yulei900609 commented on GitHub (Nov 4, 2020):

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

@yulei900609 commented on GitHub (Nov 4, 2020): i need middle-click paste very much, hope this can be done soon.

claunia commented

@albgus commented on GitHub (Nov 11, 2020):

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.

@albgus commented on GitHub (Nov 11, 2020): 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.

claunia commented

@gregory-seidman commented on GitHub (Dec 31, 2020):

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.

@gregory-seidman commented on GitHub (Dec 31, 2020): > 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.

claunia commented

@davidchisnall commented on GitHub (Jan 1, 2021):

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.

@davidchisnall commented on GitHub (Jan 1, 2021): > 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.

claunia commented

@TBBle commented on GitHub (Jan 2, 2021):

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.

@TBBle commented on GitHub (Jan 2, 2021): 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.

claunia commented

@getify commented on GitHub (Dec 28, 2021):

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

@getify commented on GitHub (Dec 28, 2021): 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

claunia commented

@ChrisHeerschap commented on GitHub (Jan 3, 2022):

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.

@ChrisHeerschap commented on GitHub (Jan 3, 2022): 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.

claunia commented

@zadjii-msft commented on GitHub (Jan 3, 2022):

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

@zadjii-msft commented on GitHub (Jan 3, 2022): > 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

claunia commented

@getify commented on GitHub (Jan 3, 2022):

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?

@getify commented on GitHub (Jan 3, 2022): 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?

claunia commented

@my-vegetable-has-exploded commented on GitHub (Feb 21, 2022):

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

@my-vegetable-has-exploded commented on GitHub (Feb 21, 2022): Is this issue still in developing？ I don't see relative setting in docs. Thanks

claunia commented

@carlos-zamora commented on GitHub (Feb 22, 2022):

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

This feature isn't under active development at the moment. It's currently placed in the "Up Next" milestone meaning that it's at the top of our backlog.

For more info on our milestones, see https://github.com/microsoft/terminal/discussions/12109

@carlos-zamora commented on GitHub (Feb 22, 2022): > Is this issue still in developing？ I don't see relative setting in docs. Thanks This feature isn't under active development at the moment. It's currently placed in the "Up Next" milestone meaning that it's at the top of our backlog. For more info on our milestones, see https://github.com/microsoft/terminal/discussions/12109

claunia commented

@getify commented on GitHub (Feb 22, 2022):

@carlos-zamora thanks for that update. Further question: what about #3990, which is proposed as a shorter path to "fixing" a somewhat breaking behavior of mouse-scroll-ctrl-zooming?

It's a small subset of this larger feature request, but presumably if it's prioritized in that same queue it might be able to be tackled much more quickly (and fix our blocker problem) while this larger feature is worked on.

@getify commented on GitHub (Feb 22, 2022): @carlos-zamora thanks for that update. Further question: what about #3990, which is proposed as a shorter path to "fixing" a somewhat breaking behavior of mouse-scroll-ctrl-zooming? It's a small subset of this larger feature request, but presumably if it's prioritized in that same queue it might be able to be tackled much more quickly (and fix our blocker problem) while this larger feature is worked on.

claunia commented

@zadjii-msft commented on GitHub (Feb 22, 2022):

Part of me thinks I'd almost rather figure out the regression than add the escape hatch. This totally seems like the kind of thing that would have regressed in #10051. I've marked #3990 as Help Wanted and Easy Starter. I don't think we're gonna have time to get on those with the other bugs on our plate in 1.14.

That being said, we should get to the bottom of the regression. @getify mind filing a separate issue for the touchpad scrolling regression? I don't want to lose track of that for 1.14

(idly: that might be related to #9955.b)

@zadjii-msft commented on GitHub (Feb 22, 2022): Part of me thinks I'd almost rather figure out the regression than add the escape hatch. This totally seems like the kind of thing that would have regressed in #10051. I've marked #3990 as `Help Wanted` and `Easy Starter`. I don't think we're gonna have time to get on those with the other bugs on our plate in 1.14. That being said, we should get to the bottom of the regression. @getify mind filing a separate issue for the touchpad scrolling regression? I don't want to lose track of that for 1.14 (idly: that might be related to #9955.b)

claunia commented

@getify commented on GitHub (Feb 22, 2022):

@zadjii-msft The "regression" is not, from what I can tell, in Terminal. I think the regression is Windows and/or the built-in touchpad drivers.

I thought initially this issue was only affecting Terminal; I hadn't experienced the problem in any other apps. That's why I came here. But another app I use does experience this same increase in the issue/sensitivity: Sublime. As far as I can tell, Terminal and Sublime are the only two apps I use which ctrl+scroll causes a zoom behavior at all, so it makes sense they're the only two where the regression/change in sensitivity has become obvious.

I've chased similar rabbit trails with Sublime, looking for some way to disable the ctrl+scroll zooming. They do have keybinding settings, and in a limited way I was able to shut off the annoying zooming behavior. However, their problem is that you can't just tell it to "ignore" the ctrl... you literally disable all actions when ctrl is held down while zooming. That's not what is desired. The outcome currently in Sublime is annoying: if I swipe to scroll, and the inertia is moving the scroll pane, and then I hit the ctrl key, all scrolling abruptly stops. There's no zoom, but I didn't want the scroll to stop like that, so it's not good.

What is desired is a setting that tells the app (Terminal or Sublime), "hey, don't treat ctrl as a special modifier while scrolling, just let scrolling continue to happen as it would if ctrl wasn't pressed".

I bring this detail up to say:

I don't think we need to fix a regression in Terminal
I hope when you add a keybinding or disabling feature into Terminal, you realize the difference between "shut all action down" and "don't pay any attention to this modifier key". The former is what Sublime did, and it sucks. The latter is what I think us users actually want.

@getify commented on GitHub (Feb 22, 2022): @zadjii-msft The "regression" is not, from what I can tell, in Terminal. I think the regression is Windows and/or the built-in touchpad drivers. I thought initially this issue was only affecting Terminal; I hadn't experienced the problem in any other apps. That's why I came here. But another app I use *does* experience this same increase in the issue/sensitivity: Sublime. As far as I can tell, Terminal and Sublime are the only two apps I use which ctrl+scroll causes a zoom behavior at all, so it makes sense they're the only two where the regression/change in sensitivity has become obvious. I've chased similar rabbit trails with Sublime, looking for some way to disable the ctrl+scroll zooming. They do have keybinding settings, and in a limited way I was able to shut off the annoying zooming behavior. However, their problem is that you can't just tell it to "ignore" the ctrl... you literally disable all actions when ctrl is held down while zooming. That's not what is desired. The outcome currently in Sublime is annoying: if I swipe to scroll, and the inertia is moving the scroll pane, and then I hit the ctrl key, all scrolling abruptly stops. There's no zoom, but I didn't want the scroll to stop like that, so it's not *good*. What is desired is a setting that tells the app (Terminal or Sublime), "hey, don't treat ctrl as a special modifier while scrolling, just let scrolling continue to happen as it would if ctrl wasn't pressed". I bring this detail up to say: 1. I don't think we need to fix a regression in Terminal 2. I hope when you add a keybinding or disabling feature into Terminal, you realize the difference between "shut all action down" and "don't pay any attention to this modifier key". The former is what Sublime did, and it sucks. The latter is what I think us users *actually* want.

claunia commented

@zadjii-msft commented on GitHub (Feb 22, 2022):

Weird. Well, looking at the code for a second, I wonder if there's an easier stop gap that could be implemented: when ctrl is pressed, cancel any current momentum in the touch scrolling. I don't even know if that's something that the input APIs let us do. But like, if you did a swipe with the trackpad, then hit Ctrl, then you probably don't want the momentum from that swipe to start zooming...

I did look at the code and I'm pretty sure the regression in #9955.b would also apply to zooming here. This is admittedly psychic debugging at work, but: Precision trackpads send many scroll events with smaller incremental scroll measurements, but I think we just adjust the font size by 1 whole size each event, not based on the actual scroll delta. Unfortunately, the zooming seemed fine on my slaptop 2 so I couldn't repro this specifically.

FWIW, the plan I have in my head for this is a lot like how keybindings work:

[
  { "button": "mouseWheelDown", "command": { "action": "scrollDown", "rollsToScroll": "${scrollDelta}" } }, // or something like that
  { "button": "ctrl+mouseWheelDown", "command": { "action": "scrollDown", "rollsToScroll": "${scrollDelta}" } } // hey look, rebind ctrl+mouse to scroll instead
]

@zadjii-msft commented on GitHub (Feb 22, 2022): Weird. Well, looking at the code for a second, I wonder if there's an easier stop gap that could be implemented: when ctrl is pressed, cancel any current momentum in the touch scrolling. I don't even know if that's something that the input APIs let us do. But like, if you did a swipe with the trackpad, then hit Ctrl, then you _probably_ don't want the momentum from that swipe to start zooming... I did look at the code and I'm pretty sure the regression in #9955.b would also apply to zooming here. This is admittedly psychic debugging at work, but: Precision trackpads send many scroll events with smaller incremental scroll measurements, but I think we just adjust the font size by 1 whole size each event, not based on the actual scroll delta. Unfortunately, the zooming seemed fine on my slaptop 2 so I couldn't repro this specifically. <hr> FWIW, the plan I have in my head for this is a lot like how keybindings work: ```jsonc [ { "button": "mouseWheelDown", "command": { "action": "scrollDown", "rollsToScroll": "${scrollDelta}" } }, // or something like that { "button": "ctrl+mouseWheelDown", "command": { "action": "scrollDown", "rollsToScroll": "${scrollDelta}" } } // hey look, rebind ctrl+mouse to scroll instead ] ```

claunia commented

@getify commented on GitHub (Feb 22, 2022):

when ctrl is pressed, cancel any current momentum in the touch scrolling.

I'm not sure if that's what we want or not... what I prefer is for ctrl to have no effect on scrolling behavior (either directly applied or through momentum) or zooming.

"cancel" implies it interferes in some way, and what I'd rather express is "ignore".

@getify commented on GitHub (Feb 22, 2022): > when ctrl is pressed, cancel any current momentum in the touch scrolling. I'm not sure if that's what we want or not... what I prefer is for ctrl to have no effect on scrolling behavior (either directly applied or through momentum) or zooming. "cancel" implies it interferes in some way, and what I'd rather express is "ignore".

claunia commented

https://github.com/microsoft/terminal/issues/3793#issuecomment-808192987

@zadjii-msft commented on GitHub (Feb 23, 2022):

Sorry I don't mean "cancel" more, "interrupt"? Like, when the user presses ctrl, maybe we should stop any current momentum that the scrolling might have. Then the user would need to start a new scroll if they wanted to zoom. That might help mitigate the issue a bit.

A similar discussion in another (admittedly totally unrelated) thread:

@zadjii-msft commented on GitHub (Feb 23, 2022): Sorry I don't mean "cancel" more, "interrupt"? Like, when the user presses ctrl, maybe we should stop any current momentum that the scrolling might have. Then the user would need to start a new scroll if they wanted to zoom. That might help mitigate the issue a bit. A similar discussion in another (admittedly totally unrelated) thread: https://github.com/microsoft/terminal/issues/3793#issuecomment-808192987

claunia commented

@getify commented on GitHub (Feb 23, 2022):

Like, when the user presses ctrl, maybe we should stop any current momentum that the scrolling might have.

That's the behavior I have in my current hack-around in Sublime, and I dislike it. I don't want hitting ctrl to have any effect on my scrolling behavior (momentum or otherwise). I also don't want holding down ctrl before scrolling to prevent the scroll from starting (which is also how my current Sublime behavior is).

@getify commented on GitHub (Feb 23, 2022): > Like, when the user presses ctrl, maybe we should stop any current momentum that the scrolling might have. That's the behavior I have in my current hack-around in Sublime, and I dislike it. I don't want hitting ctrl to have any effect on my scrolling behavior (momentum or otherwise). I also don't want holding down ctrl before scrolling to prevent the scroll from starting (which is also how my current Sublime behavior is).

claunia commented

2026-01-30 22:47:33 +00:00

@Konstantin-Glukhov commented on GitHub (May 30, 2022):

How about something like this?

"pointerbindings": [
{
"device": "mouse",
"event": "rightClickOnSelection",
"where": "terminal",
"command": "noAction"
},

@Konstantin-Glukhov commented on GitHub (May 30, 2022): How about something like this? "pointerbindings": [ { "device": "mouse", "event": "rightClickOnSelection", "where": "terminal", "command": "noAction" },

claunia commented

@samheuck commented on GitHub (Feb 10, 2023):

Is this issue dead? It's been... going on nearly 4 years since it was opened now?

I like using "Windows Terminal", but there's still no way I can find to disable "right-click to paste" / "QuickEdit" like you can in PowerShell.

@samheuck commented on GitHub (Feb 10, 2023): Is this issue dead? It's been... going on nearly 4 years since it was opened now? I like using "Windows Terminal", but there's still no way I can find to disable "right-click to paste" / "QuickEdit" like you can in PowerShell.

claunia commented

2026-01-30 22:47:33 +00:00

@cloud-66 commented on GitHub (Feb 11, 2023):

i used to middle click paste, and it's hard for me to use windows terminal without this function. i love wt , but it still doesn't have this.

@cloud-66 commented on GitHub (Feb 11, 2023): i used to middle click paste, and it's hard for me to use windows terminal without this function. i love wt , but it still doesn't have this.

claunia commented

2026-01-30 22:47:33 +00:00

@korpa commented on GitHub (Feb 11, 2023):

i used to middle click paste, and it's hard for me to use windows terminal without this function. i love wt , but it still doesn't have this.

Same here. This is the reason why I switched Windows Terminal to Alacritty a couple of weeks ago.

@korpa commented on GitHub (Feb 11, 2023): > i used to middle click paste, and it's hard for me to use windows terminal without this function. i love wt , but it still doesn't have this. Same here. This is the reason why I switched Windows Terminal to Alacritty a couple of weeks ago.

claunia commented

2026-01-30 22:47:34 +00:00

@amkartashov commented on GitHub (Feb 12, 2023):

simple autohotkey script to paste on middle button:

; Paste with middle mouse in Windows Terminal
#IfWinActive ahk_class CASCADIA_HOSTING_WINDOW_CLASS
MButton::Send ^{vk56} ; Send Ctrl-V with middle button
#IfWinActive

@amkartashov commented on GitHub (Feb 12, 2023): simple autohotkey script to paste on middle button: ``` ; Paste with middle mouse in Windows Terminal #IfWinActive ahk_class CASCADIA_HOSTING_WINDOW_CLASS MButton::Send ^{vk56} ; Send Ctrl-V with middle button #IfWinActive ```

claunia commented

2026-01-30 22:47:34 +00:00

@zadjii-msft commented on GitHub (Feb 13, 2023):

Is this issue dead? It's been... going on nearly 4 years since it was opened now?

Nope, there's just plenty of other higher-priority work unfortunately. I've got a draft PR for an experimental setting just for the right-click context menu over in #14775. We however don't have a full spec for how we'd actually like to express the fullness of mouse bindings. That's the biggest blocker here - someone taking the time to enumerate what people have asked for and what's possible, and putting them together into a spec.

Do folks want to bind arbitrary actions to mouse buttons, or really only a subset of actions?
Does this become an extension of bindings, with new "keys" values to indicate mouse buttons?
Should configuring the number of lines to scroll be a part of this? Like, rebinding mouseWheelDown to scrollDown(5)? Or is that a separate (but related) setting?
How do we represent multi-clicks and multi-click actions? (|double|triple)(Left|Middle|Right)Click seems... verbose...

Those are the thoughts from the top of the dome. If someone wants to put together a proposal, I'd love to review it. Writing the code shouldn't be that hard, so long as we have the right design in place ☺️

@zadjii-msft commented on GitHub (Feb 13, 2023): > Is this issue dead? It's been... going on nearly 4 years since it was opened now? Nope, there's just plenty of other higher-priority work unfortunately. I've got a draft PR for an experimental setting just for the right-click context menu over in #14775. We however don't have a full spec for how we'd actually like to express the fullness of mouse bindings. That's the biggest blocker here - someone taking the time to enumerate what people have asked for and what's possible, and putting them together into a spec. * Do folks want to bind _arbitrary_ actions to mouse buttons, or really only a subset of actions? * Does this become an extension of `bindings`, with new "`keys`" values to indicate mouse buttons? * Should configuring the number of lines to scroll be a part of this? Like, rebinding `mouseWheelDown` to `scrollDown(5)`? Or is that a separate (but related) setting? * How do we represent multi-clicks and multi-click actions? `(|double|triple)(Left|Middle|Right)Click` seems... verbose... Those are the thoughts from the top of the dome. If someone wants to put together a proposal, I'd love to review it. Writing the code shouldn't be that hard, so long as we have the right design in place ☺️

claunia commented

2026-01-30 22:47:34 +00:00

@hmb commented on GitHub (Apr 6, 2023):

Well, the most pressing issue is probably to just paste the clipboard with the middle mouse button. As many linux terminals, e.g. in VMs, X-Servers like Xming, even in the windows version of git-bash, "paste" is always the middle mouse click. So using the right click in ms-terminal makes it kind of random to which click has to be used:

git-bash native -> middle click
git-bash embedded in ms-terminal -> right click
linux VM -> middle click

Guess what: you always use the wrong one. So in terms of a hamonized user exp would suffice for starters to "paste" with middle mouse button. The "generic covering all eventualities mouse configurator" is probably overkill for all those working in a hybrid environment.

@hmb commented on GitHub (Apr 6, 2023): Well, the most pressing issue is probably to just paste the clipboard with the middle mouse button. As many linux terminals, e.g. in VMs, X-Servers like Xming, even in the windows version of git-bash, "paste" is always the middle mouse click. So using the right click in ms-terminal makes it kind of random to which click has to be used: - git-bash native -> middle click - git-bash embedded in ms-terminal -> right click - linux VM -> middle click Guess what: you always use the wrong one. So in terms of a hamonized user exp would suffice for starters to "paste" with middle mouse button. The "generic covering all eventualities mouse configurator" is probably overkill for all those working in a hybrid environment.

claunia commented

@lucky-wolf commented on GitHub (Oct 21, 2023):

Wow, 5y and not solved?

A trivial way to disable "quickedit" would suffice.

@lucky-wolf commented on GitHub (Oct 21, 2023): Wow, 5y and not solved? A trivial way to disable "quickedit" would suffice.

claunia commented

@zadjii-msft commented on GitHub (Oct 21, 2023):

I mean, there is: experimental.rightClickContextMenu

@zadjii-msft commented on GitHub (Oct 21, 2023): I mean, there is: [`experimental.rightClickContextMenu`](https://learn.microsoft.com/en-us/windows/terminal/customize-settings/profile-advanced#right-click-context-menu-preview)

claunia commented

@TheZetner commented on GitHub (Nov 8, 2023):

simple autohotkey script to paste on middle button:

; Paste with middle mouse in Windows Terminal
#IfWinActive ahk_class CASCADIA_HOSTING_WINDOW_CLASS
MButton::Send ^{vk56} ; Send Ctrl-V with middle button
#IfWinActive

Just updated this to AHK 2.0:

; Paste with middle mouse in Windows Terminal
#HotIf WinActive("ahk_class CASCADIA_HOSTING_WINDOW_CLASS")
MButton::Send "^{vk56}" ; Send Ctrl-V with middle button

@TheZetner commented on GitHub (Nov 8, 2023): > simple autohotkey script to paste on middle button: > > ``` > ; Paste with middle mouse in Windows Terminal > #IfWinActive ahk_class CASCADIA_HOSTING_WINDOW_CLASS > MButton::Send ^{vk56} ; Send Ctrl-V with middle button > #IfWinActive > ``` Just updated this to AHK 2.0: ``` ; Paste with middle mouse in Windows Terminal #HotIf WinActive("ahk_class CASCADIA_HOSTING_WINDOW_CLASS") MButton::Send "^{vk56}" ; Send Ctrl-V with middle button ```

claunia commented

2026-01-30 22:47:36 +00:00

@psergiu commented on GitHub (May 23, 2024):

It's 2024 and it's still not added :( Some companies don't allow the use of AutoHotKey on work machines. Please just add a simple "X11-style middle mouse button paste" option and it's perfect. If there's time to add more options in the future, even better.
Thank you.

@psergiu commented on GitHub (May 23, 2024): It's 2024 and it's still not added :( Some companies don't allow the use of AutoHotKey on work machines. Please just add a simple "X11-style middle mouse button paste" option and it's perfect. If there's time to add more options in the future, even better. Thank you.

claunia commented

@johny-mnemonic commented on GitHub (Feb 23, 2025):

Really? Instead of finally adding this simple config option, you are now deleting user comments? 😮
That's the way to go!

Looking forward to have my comment deleted as well🙄

@johny-mnemonic commented on GitHub (Feb 23, 2025): Really? Instead of finally adding this simple config option, you are now deleting user comments? 😮 That's the way to go! Looking forward to have my comment deleted as well🙄

claunia commented

2026-01-30 22:47:36 +00:00

@psergiu commented on GitHub (Feb 23, 2025):

The lack of this simple feature has lost Microsoft more licensing revenue just at companies I worked at than it would have cost to pay a developer for a full year to implement-it. Apple is very thankful for all the Macs sold because "Windows Terminal is not compatible with our Linux servers"

@psergiu commented on GitHub (Feb 23, 2025): The lack of this simple feature has lost Microsoft more licensing revenue just at companies I worked at than it would have cost to pay a developer for a full year to implement-it. Apple is very thankful for all the Macs sold because "Windows Terminal is not compatible with our Linux servers"

claunia commented

2026-01-30 22:47:36 +00:00

@jemand771 commented on GitHub (Feb 23, 2025):

can y'all PLEASE stop venting your frustration in github issues?
this feature request has been liked by 133 people, most of which I'd assume are subscribed to notifications.

please consider how many patiently waiting users (who are in the same situation as you!) you're pinging vs. what you actually achieve here before posting.

@jemand771 commented on GitHub (Feb 23, 2025): can y'all PLEASE stop venting your frustration in github issues? this feature request has been liked by 133 people, most of which I'd assume are subscribed to notifications. please consider how many patiently waiting users (who are in the same situation as you!) you're pinging vs. what you actually achieve here before posting.

claunia commented

@zadjii-msft commented on GitHub (Feb 24, 2025):

Prelle's comment was deleted because it was whinging. This:

does not bring anything valuable to this conversation. I won't stand for whinging. Productive, constructive discussion - that I'm more than happy to have.

The lack of this simple feature has lost Microsoft more licensing revenue

I'd love to see concrete evidence that the lack of middle-click-to-paste in the Terminal is truly causing Microsoft to lose revenue. Genuinely: solid evidence of that would probably allow us to instantaneously prioritize this work. Rarely do we get the opportunity to directly correlate individual features in a developer tool to direct dollars and cents. Please, if you have that data, I'd love to share it.

Once again: I'd be more than willing to listen to and review a proposal here. It's a complicated problem space, to try and appropriately map all the requests to proper mouse bindings here.

My notes from: https://github.com/microsoft/terminal/issues/1553#issuecomment-1428827890 still apply.

The last attempt I made at this was in 2024, and I pushed my notes here: https://github.com/microsoft/terminal/compare/main...dev/migrie/s/1553-mouse-bindings. ¹ I got bogged down in the potential syntax to address the multitude of linked features here.

genuinely, I remember writing more than that, but I've had a kid since then so I forgot where I may have put any other notes I had. Push early and often folks. ↩︎

@zadjii-msft commented on GitHub (Feb 24, 2025): Prelle's comment was deleted because it was _whinging_. This: ![Image](https://github.com/user-attachments/assets/6440dba5-2c50-4ef0-8170-de79613a77ac) does not bring anything valuable to this conversation. I won't stand for whinging. Productive, constructive discussion - that I'm more than happy to have. > The lack of this simple feature has lost Microsoft more licensing revenue I'd **_love_** to see concrete evidence that the lack of middle-click-to-paste in the Terminal is truly causing Microsoft to lose revenue. **Genuinely**: solid evidence of that would probably allow us to **instantaneously** prioritize this work. Rarely do we get the opportunity to directly correlate individual features in a developer tool to direct dollars and cents. Please, if you have that data, I'd love to share it. ---- Once again: I'd be more than willing to listen to and review a proposal here. It's a complicated problem space, to try and appropriately map all the requests to proper mouse bindings here. My notes from: https://github.com/microsoft/terminal/issues/1553#issuecomment-1428827890 still apply. The last attempt I made at this was in 2024, and I pushed my notes here: https://github.com/microsoft/terminal/compare/main...dev/migrie/s/1553-mouse-bindings. [^1] I got bogged down in the potential syntax to address the multitude of linked features here. [^1]: genuinely, I remember writing more than that, but I've had a kid since then so I forgot where I may have put any other notes I had. Push early and often folks.

claunia commented

@johny-mnemonic commented on GitHub (Feb 24, 2025):

@zadjii-msft Unfortunately it looks like we are asking for making one small fixed window openable and your reply is that until your team figures out how to completely rebuild the whole cathedral that small window will remain fixed😢

I hope this explains the source of frustration and maybe even sparks some interest in actually solving this simple issue without the need to wait for the complete re-factor of the Terminal controls🙏

@johny-mnemonic commented on GitHub (Feb 24, 2025): @zadjii-msft Unfortunately it looks like we are asking for making one small fixed window openable and your reply is that until your team figures out how to completely rebuild the whole cathedral that small window will remain fixed😢 I hope this explains the source of frustration and maybe even sparks some interest in actually solving this simple issue without the need to wait for the complete re-factor of the Terminal controls🙏

claunia commented

@zadjii-msft commented on GitHub (Feb 24, 2025):

Implementing it in the control itself would be fairly trivial. Authoring a JSON schema that can be used to consisely describe the breadth of what people what to be able to configure about the mouse - that's hard. That's what I'm very open to suggestions on.

@zadjii-msft commented on GitHub (Feb 24, 2025): Implementing it in the control itself would be fairly trivial. Authoring a JSON schema that can be used to consisely describe the breadth of what people what to be able to configure about the mouse - that's hard. That's what I'm very open to suggestions on.

claunia commented

2026-01-30 22:47:38 +00:00

@psergiu commented on GitHub (Feb 24, 2025):

For starters, just being able to paste with the middle mouse button would appease a lot of Unix/Linux people.
X11 XTerm has middle-mouse: paste, right-mouse: extend existing selection.
Thank you !

@psergiu commented on GitHub (Feb 24, 2025): For starters, just being able to paste with the middle mouse button would appease a lot of Unix/Linux people. X11 XTerm has middle-mouse: paste, right-mouse: extend existing selection. Thank you !

claunia commented

@venzy commented on GitHub (Feb 24, 2025):

Thanks Mike,

I wonder whether short-medium term, a per profile option or two a bit like
PuTTY has would suffice?

In PuTTy - Radio selection:
a. Middle extends, Right brings up menu
b. Middle extends, Right pastes
c. Right extends, Middle pastes

I’d add:
d. Middle pastes, Right brings up menu - that’s what many gnome-terminal
and perhaps other users are used to. It’s what I would use, even in
PowerShell and Cmd terminals.

Cheers,
-Dave

On Tue, 25 Feb 2025 at 5:46 am, psergiu @.***> wrote:

For starters, just being able to paste with the middle mouse button would
appease a lot of Unix/Linux people.
X11 XTerm has middle-mouse: paste, right-mouse: extend existing selection.
Thank you !

—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/1553#issuecomment-2679484838,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAPBQUKUKR2STSA2AZZNTAD2RNZHVAVCNFSM6AAAAABXSJS3BWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZGQ4DIOBTHA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>
[image: psergiu]psergiu left a comment (microsoft/terminal#1553)
https://github.com/microsoft/terminal/issues/1553#issuecomment-2679484838

For starters, just being able to paste with the middle mouse button would
appease a lot of Unix/Linux people.
X11 XTerm has middle-mouse: paste, right-mouse: extend existing selection.
Thank you !

—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/1553#issuecomment-2679484838,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAPBQUKUKR2STSA2AZZNTAD2RNZHVAVCNFSM6AAAAABXSJS3BWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZGQ4DIOBTHA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@venzy commented on GitHub (Feb 24, 2025): Thanks Mike, I wonder whether short-medium term, a per profile option or two a bit like PuTTY has would suffice? In PuTTy - Radio selection: a. Middle extends, Right brings up menu b. Middle extends, Right pastes c. Right extends, Middle pastes I’d add: d. Middle pastes, Right brings up menu - that’s what many gnome-terminal and perhaps other users are used to. It’s what I would use, even in PowerShell and Cmd terminals. Cheers, -Dave On Tue, 25 Feb 2025 at 5:46 am, psergiu ***@***.***> wrote: > For starters, just being able to paste with the middle mouse button would > appease a lot of Unix/Linux people. > X11 XTerm has middle-mouse: paste, right-mouse: extend existing selection. > Thank you ! > > — > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/1553#issuecomment-2679484838>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAPBQUKUKR2STSA2AZZNTAD2RNZHVAVCNFSM6AAAAABXSJS3BWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZGQ4DIOBTHA> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > [image: psergiu]*psergiu* left a comment (microsoft/terminal#1553) > <https://github.com/microsoft/terminal/issues/1553#issuecomment-2679484838> > > For starters, just being able to paste with the middle mouse button would > appease a lot of Unix/Linux people. > X11 XTerm has middle-mouse: paste, right-mouse: extend existing selection. > Thank you ! > > — > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/1553#issuecomment-2679484838>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAPBQUKUKR2STSA2AZZNTAD2RNZHVAVCNFSM6AAAAABXSJS3BWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZZGQ4DIOBTHA> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

claunia commented

2026-01-30 22:47:38 +00:00

@jypeter commented on GitHub (Feb 25, 2025):

For the record, and for those who don't use PuTTY, there is a screenshot of the PuTTY selection settings in my old duplicate issue

I mostly use PuTTY (for other reasons than just copy/paste), but I have learned to deal with the Windows Terminal (that also has nice features) when I need it, by simply using:

the option (specified in Settings => Interaction) where raw selected text is automatically copied to the clipboard (same behavior as xterm). I appreciate the fact that double clicking selects a word, and triple selects a line, the same way you do this in an xterm
pasting with the right button (or ctrl+v)

I can live with that, even if it feels a bit awkward. The trouble is that when we try to teach modern students that they have to remember different ways of copy/pasting, depending on the application, they don't want to bother

@jypeter commented on GitHub (Feb 25, 2025): For the record, and for those who don't use PuTTY, there is a screenshot of the PuTTY _selection_ settings in [my old duplicate issue](https://github.com/microsoft/terminal/issues/7646) I mostly use PuTTY (for other reasons than just copy/paste), but I have learned to deal with the Windows Terminal (that also has nice features) when I need it, by simply using: - the option (specified in `Settings => Interaction`) where **raw** selected text is automatically copied to the clipboard (same behavior as `xterm`). I appreciate the fact that double clicking selects a word, and triple selects a line, the same way you do this in an xterm - pasting with the right button (or `ctrl+v`) I can live with that, even if it _feels_ a bit awkward. The trouble is that when we try to teach modern students that they have to remember different ways of copy/pasting, depending on the application, they don't want to bother

claunia commented

@Nahor commented on GitHub (Feb 25, 2025):

Implementing it in the control itself would be fairly trivial. Authoring a JSON schema that can be used to consisely describe the breadth of what people what to be able to configure about the mouse - that's hard. That's what I'm very open to suggestions on.

"Perfect is the enemy of good": given that this issue has existed in one form or another since Windows and Unix have co-existed, I think waiting for the perfect configuration is a mistake. I think a configuration with simple bindings with a path forward to extend it later (aka some ideas on how to do it) for other options/features/parameters should be enough. And if a completely new setting or way of doing things is needed later, while not ideal, it should also be fairly easy to have Terminal either support both methods or to automatically upgrade the configuration to the new format.
There is already a schema for bindings: keyboard bindings. I don't think the mouse should be a separate thing:
- I believe we should have click, double-click, right-click, ... "keys" and be in the same keybindings section. Alternatively (or in addition), keys could be parameterized (more about that later)
- For the action parameters (regex, delimiters, amount of scrolled lines, ...), this isn't a mouse-only issue, the keyboard shortcuts could also make use of those
- Having a single binding configuration would also help support/unify non standard keys/devices (scroll wheels on fancy keyboards, accessibility devices, ...)
The existing schema supports nearly everything needed:
- actions can have parameters, e.g. the splitPane command
- actions are separated from keybindings, which allows for actions to be used by multiple bindings (i.e. shared action configuration)
- one missing thing is parameters for the keybindings¹, e.g. number of clicks but that's trivial (by some definition I guess) to fix by allowing the JSON schema to accept both "values" (like today) and "objects (map/array) for keys entries, or having a different entry (e.g. keys for simple key, keyConfig for complex/parameterized ones). This would allow things like click: {button: [left,right,middle,<number>], numberOfClicks: [double, triple, <number>], delayBetweenClicks: <milliseconds>} or scrollwheel: {speed: <number>, wheel: [vertical,horizontal,<number>]}
  @zadjii-msft mentioned verbosity as being a problem, but I don't think that can be avoided. That it be in the name of the key (DoubleLeftClick) or in the parameters (Click(left, 2)), details are verbose by definition. The only way to simplify is by omitting the details and defaulting them (e.g. Click == SingleLeftClick == Click(left, 1) == Click(button: "left", count: 1))

The TLDR:

there is already a perfectly good schema which should also be easily extended if necessary
this particular issue has existed since the beginning of Terminal, and the general form since cmd.exe, IMHO it's worth fixing it even in a non-perfect way just to silence the majority of the complaints.

I see mention of KeyChordSegment in the schema, so maybe there is already some form of parameterization ↩︎

@Nahor commented on GitHub (Feb 25, 2025): > Implementing it in the control itself would be fairly trivial. Authoring a JSON schema that can be used to consisely describe the breadth of what people what to be able to configure about the mouse - that's hard. That's what I'm very open to suggestions on. 1. "Perfect is the enemy of good": given that this issue has existed in one form or another since Windows and Unix have co-existed, I think waiting for the perfect configuration is a mistake. I think a configuration with simple bindings with a path forward to extend it later (aka some ideas on how to do it) for other options/features/parameters should be enough. And if a completely new setting or way of doing things is needed later, while not ideal, it should also be fairly easy to have Terminal either support both methods or to automatically upgrade the configuration to the new format. 2. There is already a schema for bindings: keyboard bindings. I don't think the mouse should be a separate thing: - I believe we should have click, double-click, right-click, ... "keys" and be in the same `keybindings` section. Alternatively (or in addition), `keys` could be parameterized (more about that later) - For the action parameters (regex, delimiters, amount of scrolled lines, ...), this isn't a mouse-only issue, the keyboard shortcuts could also make use of those - Having a single binding configuration would also help support/unify non standard keys/devices (scroll wheels on fancy keyboards, accessibility devices, ...) 3. The existing schema supports nearly everything needed: - actions can have parameters, e.g. the `splitPane` command - `actions` are separated from `keybindings`, which allows for actions to be used by multiple bindings (i.e. shared action configuration) - one missing thing is parameters for the `keybindings`[^1], e.g. number of clicks but that's trivial (by some definition I guess) to fix by allowing the JSON schema to accept both "values" (like today) and "objects (map/array) for `keys` entries, or having a different entry (e.g. `keys` for simple key, `keyConfig` for complex/parameterized ones). This would allow things like `click: {button: [left,right,middle,<number>], numberOfClicks: [double, triple, <number>], delayBetweenClicks: <milliseconds>}` or `scrollwheel: {speed: <number>, wheel: [vertical,horizontal,<number>]}` @zadjii-msft mentioned verbosity as being a problem, but I don't think that can be avoided. That it be in the name of the key (`DoubleLeftClick`) or in the parameters (`Click(left, 2)`), details are verbose by definition. The only way to simplify is by omitting the details and defaulting them (e.g. `Click` == `SingleLeftClick` == `Click(left, 1)` == `Click(button: "left", count: 1)`) The TLDR: - there is already a perfectly good schema which should also be easily extended if necessary - this particular issue has existed since the beginning of Terminal, and the general form since `cmd.exe`, IMHO it's worth fixing it even in a non-perfect way just to silence the majority of the complaints. [^1]: I see mention of `KeyChordSegment` in the schema, so maybe there is already some form of parameterization

claunia commented

@inko94 commented on GitHub (Mar 2, 2025):

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

#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": "^.*$" }
}

@inko94 commented on GitHub (Mar 2, 2025): > # 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: > ```js > "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 > <kbd>Shift</kbd>/<kbd>Alt</kbd>/<kbd>Ctrl</kbd> clicks. > > > ```json > "mouse": { > "clicks": { > { "click": "double", "command": { "action": "expandSelection", "delimeters": " /\\()\"'-.,:;<>~!@#$%^&*|+=[]{}~?\u2502" } } > { "click": "shift+double", "command": { "action": "expandSelection", "delimeters": " " } } > { "click": "triple", "command": { "action": "expandSelection", "regex": "^.*$" } } > } > } > ``` > > Alternatively, > > ```json > "mouse": { > "doubleClick": " /\\()\"'-.,:;<>~!@#$%^&*|+=[]{}~?\u2502", > "tripleClick": { "regex": "^.*$" } > } > ``` > > [#3337]: https://github.com/microsoft/terminal/issues/3337 > [#6182]: https://github.com/microsoft/terminal/issues/6182 > [#6250]: https://github.com/microsoft/terminal/issues/6250 > [#6511]: https://github.com/microsoft/terminal/issues/6511 > [#7173]: https://github.com/microsoft/terminal/issues/7173 > [#7646]: https://github.com/microsoft/terminal/issues/7646 > [#9881]: https://github.com/microsoft/terminal/issues/9881 > [#10802]: https://github.com/microsoft/terminal/issues/10802 > [#11710]: https://github.com/microsoft/terminal/issues/11710 > [#11906]: https://github.com/microsoft/terminal/issues/11906 > [#13598]: https://github.com/microsoft/terminal/issues/13598 > [#17610]: https://github.com/microsoft/terminal/issues/17610 >

claunia commented

@dofuuz commented on GitHub (Mar 3, 2025):

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.

@dofuuz commented on GitHub (Mar 3, 2025): 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. ```js "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. ```js "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.

claunia commented

@Nahor commented on GitHub (Mar 3, 2025):

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

@Nahor commented on GitHub (Mar 3, 2025): > * The mouse has few buttons, so we can simplify the configuration. Some mouse such as the [Razer Naga](https://en.wikipedia.org/wiki/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".

claunia commented

@dofuuz commented on GitHub (Mar 4, 2025):

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.

@dofuuz commented on GitHub (Mar 4, 2025): > Some mouse such as the [Razer Naga](https://en.wikipedia.org/wiki/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.

claunia commented

@Nahor commented on GitHub (Mar 4, 2025):

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 commented on GitHub (Mar 4, 2025): > 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

claunia commented

@dofuuz commented on GitHub (Mar 4, 2025):

@Nahor

Not every mouse driver supports per app mouse binding. And also, https://github.com/microsoft/terminal/issues/1553#issuecomment-2128032082

https://github.com/microsoft/terminal/issues/1553#issuecomment-2679471596
MS teams are open for suggestion about breadth of configure about the mouse.

There are many, many comments requesting similar simple middle click paste.
https://github.com/microsoft/terminal/issues/1553#issuecomment-721480552 https://github.com/microsoft/terminal/issues/1553#issuecomment-1426756992 https://github.com/microsoft/terminal/issues/1553#issuecomment-1426826339 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?

@dofuuz commented on GitHub (Mar 4, 2025): @Nahor Not every mouse driver supports per app mouse binding. And also, https://github.com/microsoft/terminal/issues/1553#issuecomment-2128032082 https://github.com/microsoft/terminal/issues/1553#issuecomment-2679471596 MS teams are open for suggestion about breadth of configure about the mouse. There are many, many comments requesting similar simple middle click paste. https://github.com/microsoft/terminal/issues/1553#issuecomment-721480552 https://github.com/microsoft/terminal/issues/1553#issuecomment-1426756992 https://github.com/microsoft/terminal/issues/1553#issuecomment-1426826339 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?

claunia commented

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

@zoredache commented on GitHub (Mar 4, 2025):

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

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.

@zoredache commented on GitHub (Mar 4, 2025): 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.

claunia commented

@Nahor commented on GitHub (Mar 4, 2025):

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" */
   }
}

@Nahor commented on GitHub (Mar 4, 2025): > 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](1553#issuecomment-2682894158). > * 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" */ } } ```

claunia commented

@jypeter commented on GitHub (Mar 5, 2025):

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

@jypeter commented on GitHub (Mar 5, 2025): Indeed, I [don't need double middle-click or triple right-click](https://github.com/microsoft/terminal/issues/1553#issuecomment-2694963924). 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 ![Image](https://github.com/user-attachments/assets/bd5aa9d1-02e7-4303-8bf7-ead7a50ac275)

claunia commented

@fmad commented on GitHub (Oct 22, 2025):

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

@fmad commented on GitHub (Oct 22, 2025): 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...

claunia commented