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

[Terminal] VT Mouse Support #801

New Issue
Closed
opened 2026-01-30 22:04:37 +00:00 by claunia · 44 comments
claunia commented 2026-01-30 22:04:37 +00:00
Owner
Copy Link

Originally created by @cerebrate on GitHub (May 8, 2019).

Originally assigned to: @carlos-zamora on GitHub.

  • Your Windows build number: (Type ver at a Windows Command Prompt)

10.0.18890.1000

  • What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

I routinely use mouse mode in tmux with WSL for window selection, pane resizing, and scrollback, enabled in tmux.conf thus:

  # -- mouse support ---------------------------------------------------------                                                                                                                                                                                        
  # Enable mouse control (clickable windows, panes, resizable panes)                                                                
  set -g mouse on

While this works perfectly in conhost, it does not work at all in Terminal; nothing happens, as if the mouse events were never reaching tmux.

  • What's wrong / what should be happening instead:

tmux mouse support (and presumably other mouse-supporting applications) should work as they do in conhost.

Originally created by @cerebrate on GitHub (May 8, 2019). Originally assigned to: @carlos-zamora on GitHub. * Your Windows build number: (Type `ver` at a Windows Command Prompt) 10.0.18890.1000 * What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots) I routinely use mouse mode in tmux with WSL for window selection, pane resizing, and scrollback, enabled in tmux.conf thus: ``` # -- mouse support --------------------------------------------------------- # Enable mouse control (clickable windows, panes, resizable panes) set -g mouse on ``` While this works perfectly in conhost, it does not work at all in Terminal; nothing happens, as if the mouse events were never reaching tmux. * What's wrong / what should be happening instead: tmux mouse support (and presumably other mouse-supporting applications) should work as they do in conhost.
claunia commented 2026-01-30 22:04:39 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 8, 2019):

Yea, this is a known issue at the moment. We need to add support for mouse in two places: both in the terminal, to be able to synthesize mouse sequences, and in conpty to be able to read mouse sequences.

This issue is tracking the first bit, the Terminal functionality.

For the second bit, the conpty part, see #376.

@zadjii-msft commented on GitHub (May 8, 2019): Yea, this is a known issue at the moment. We need to add support for mouse in two places: both in the terminal, to be able to synthesize mouse sequences, and in conpty to be able to read mouse sequences. This issue is tracking the first bit, the Terminal functionality. For the second bit, the conpty part, see #376.
claunia commented 2026-01-30 22:04:39 +00:00
Author
Owner
Copy Link

@guibirow commented on GitHub (Jun 25, 2019):

Sadly this does not work, having the mouse events with TMUX would defer the need to have multiple panes.
I hope this feature get implemented before the panes, is much needed and will solve most of issues

@guibirow commented on GitHub (Jun 25, 2019): Sadly this does not work, having the mouse events with TMUX would defer the need to have multiple panes. I hope this feature get implemented before the panes, is much needed and will solve most of issues
claunia commented 2026-01-30 22:04:39 +00:00
Author
Owner
Copy Link

@jgkawell commented on GitHub (Jun 28, 2019):

I would like to point out that the mouse support is also not supported in tmux within Docker (through Powershell). I know this is because the functionality simply isn't there in Terminal so of course it won't work in WSL or Docker, but thought I'd go ahead and mention it.

@jgkawell commented on GitHub (Jun 28, 2019): I would like to point out that the mouse support is also not supported in tmux within Docker (through Powershell). I know this is because the functionality simply isn't there in Terminal so of course it won't work in WSL or Docker, but thought I'd go ahead and mention it.
claunia commented 2026-01-30 22:04:40 +00:00
Author
Owner
Copy Link

@guibirow commented on GitHub (Jun 28, 2019):

the mouse does work with TMUX in WSL

@guibirow commented on GitHub (Jun 28, 2019): the mouse does work with TMUX in WSL
claunia commented 2026-01-30 22:04:40 +00:00
Author
Owner
Copy Link

@kumarharsh commented on GitHub (Jun 28, 2019):

Mouse works with wsltty: https://github.com/mintty/wsltty

@kumarharsh commented on GitHub (Jun 28, 2019): Mouse works with wsltty: https://github.com/mintty/wsltty
claunia commented 2026-01-30 22:04:40 +00:00
Author
Owner
Copy Link

@jgkawell commented on GitHub (Jun 28, 2019):

@guibirow Maybe it's an issue with Docker from within Terminal then.

@jgkawell commented on GitHub (Jun 28, 2019): @guibirow Maybe it's an issue with Docker from within Terminal then.
claunia commented 2026-01-30 22:04:40 +00:00
Author
Owner
Copy Link

@kumarharsh commented on GitHub (Jun 28, 2019):

No. It's not an issue with Docker. It's an issue with conpty (this repo). Try wsltty if you want mouse support.

@kumarharsh commented on GitHub (Jun 28, 2019): No. It's not an issue with Docker. It's an issue with conpty (this repo). Try wsltty if you want mouse support.
claunia commented 2026-01-30 22:04:40 +00:00
Author
Owner
Copy Link

@jgkawell commented on GitHub (Jun 28, 2019):

Are there plans to enable full mouse support in tmux for Docker in the future through Terminal?

@jgkawell commented on GitHub (Jun 28, 2019): Are there plans to enable full mouse support in tmux for Docker in the future through Terminal?
claunia commented 2026-01-30 22:04:41 +00:00
Author
Owner
Copy Link

@kumarharsh commented on GitHub (Jun 28, 2019):

I don't know about Docker specifically, but i don't see why it should be any different than a normal terminal. This issue is about that, so keep an eye out!

@kumarharsh commented on GitHub (Jun 28, 2019): I don't know about Docker specifically, but i don't see why it should be any different than a normal terminal. This issue is about that, so keep an eye out!
claunia commented 2026-01-30 22:04:41 +00:00
Author
Owner
Copy Link

@jgkawell commented on GitHub (Jun 28, 2019):

So I just checked tmux through WSL 1 in Terminal and the mouse isn't supported there either. So my guess is that tmux itself just doesn't work in Terminal at this point and that it's not a Docker issue. Not sure what @guibirow was seeing on his end.

@jgkawell commented on GitHub (Jun 28, 2019): So I just checked tmux through WSL 1 in Terminal and the mouse isn't supported there either. So my guess is that tmux itself just doesn't work in Terminal at this point and that it's not a Docker issue. Not sure what @guibirow was seeing on his end.
claunia commented 2026-01-30 22:04:41 +00:00
Author
Owner
Copy Link

@guibirow commented on GitHub (Jun 28, 2019):

You have to run a command to enable it, isn't enabled by default.
I don't have it right now, but it is simple like this set mouse on
I will have to confirm next week when I get my laptop

It only works on wsl terminal though, not in the new windows terminal

@guibirow commented on GitHub (Jun 28, 2019): You have to run a command to enable it, isn't enabled by default. I don't have it right now, but it is simple like this `set mouse on` I will have to confirm next week when I get my laptop It only works on wsl terminal though, not in the new windows terminal
claunia commented 2026-01-30 22:04:42 +00:00
Author
Owner
Copy Link

@jgkawell commented on GitHub (Jun 28, 2019):

Oh I gotcha. Yeah it works fine in the plain WSL window. It only fails to work when embedded within the new Windows Terminal.

@jgkawell commented on GitHub (Jun 28, 2019): Oh I gotcha. Yeah it works fine in the plain WSL window. It only fails to work when embedded within the new Windows Terminal.
claunia commented 2026-01-30 22:04:42 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Jul 9, 2019):

If you implement mouse support, please make sure to implement the SGR (1006) extension as well.

The legacy, byte-based protocol only allows row and column numbers up to 223, because 32 is added to this number and this is sent as a single byte. The column limit is not uncommon to be too small. (By the way, beginning at column 95 the generated data is not 7-bit clean and not valid UTF-8 which is a problem for encoding conversion layers such as luit.)

The SGR 1006 extension fixes these problems by encoding the numbers as decimal digits, and is supported by plenty of applications.

If this extension is not requested, please don't generate any event if the row or column exceeds 223. Otherwise an overflow could have nasty consequences. E.g. clicking on column 227 could generate the byte 32+227 = 259 = 3 = Ctrl+C which is typically the interrupt character sending a SIGINT to the running process.

@egmontkob commented on GitHub (Jul 9, 2019): If you implement mouse support, please make sure to implement the SGR (1006) extension as well. The legacy, byte-based protocol only allows row and column numbers up to 223, because 32 is added to this number and this is sent as a single byte. The column limit is not uncommon to be too small. (By the way, beginning at column 95 the generated data is not 7-bit clean and not valid UTF-8 which is a problem for encoding conversion layers such as luit.) The SGR 1006 extension fixes these problems by encoding the numbers as decimal digits, and is supported by plenty of applications. If this extension is not requested, please don't generate any event if the row or column exceeds 223. Otherwise an overflow could have nasty consequences. E.g. clicking on column 227 could generate the byte 32+227 = 259 = 3 = Ctrl+C which is typically the interrupt character sending a SIGINT to the running process.
claunia commented 2026-01-30 22:04:42 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 9, 2019):

So! Conhost actually does support DECSET 1006! Since we have this intervening layer (the pseudoconsole, which needs to talk to conhost), we get to choose what sort of mouse mode the pseudoconsole requests and supports. I see no reason that that shouldn't just be 1006 😄 Thanks for the info!

@DHowett-MSFT commented on GitHub (Jul 9, 2019): So! Conhost actually does support DECSET `1006`! Since we have this intervening layer (the pseudoconsole, which needs to talk to conhost), we get to choose what sort of mouse mode the pseudoconsole requests and supports. I see no reason that that shouldn't just be `1006` :smile: Thanks for the info!
claunia commented 2026-01-30 22:04:43 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 9, 2019):

To clarify, because we have conhost in the middle, that would look like this:

                                      +-----------------+
                                      |                 |
                 DECSET 1002, 1005    | Windows conhost |
+-------------+                       |  (in PTY mode)  |
|             +----------------------->                 |
| Application |                       |                 |
|             <-----------------------+                 |
+-------------+                       |                 |
                 mouse information    |                 |
                 1002 in 1005 format  |                 |
                                      |                 |
                                      +---+---------^---+
                                          |         |
                                          |         | mouse information in
                         DECSET 1002,1006 |         | SGR Extended Format
                                          |         | (1002+1006)
                                          |         |
                                      +---v---------+---+
                                      |                 |
                                      | Windows         |
                                      |  Terminal       |
                                      |                 |
                                      |                 |
                                      |                 |
                                      |                 |
                                      +-----------------+
@DHowett-MSFT commented on GitHub (Jul 9, 2019): To clarify, because we have conhost in the middle, that would look like this: ``` +-----------------+ | | DECSET 1002, 1005 | Windows conhost | +-------------+ | (in PTY mode) | | +-----------------------> | | Application | | | | <-----------------------+ | +-------------+ | | mouse information | | 1002 in 1005 format | | | | +---+---------^---+ | | | | mouse information in DECSET 1002,1006 | | SGR Extended Format | | (1002+1006) | | +---v---------+---+ | | | Windows | | Terminal | | | | | | | | | +-----------------+ ```
claunia commented 2026-01-30 22:04:43 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Jul 9, 2019):

Did you mean 1005 between the application and conhost, or is that a typo in this picture? Mouse extensions 1005 and 1015 also exist but they are hardly used (if at all) due to their flaws, it's not something that applications are interested in.

1005 (xterm's two-byte UTF-8), 1015 (urxvt) and 1006 (xterm SGR), in this chronological order, are three mutually exclusive extensions to address the limitation of the column number. See e.g. Midnight Commander issues 2662 and 2956 for technical description about the flaws of the first two. Note that this story is now 6-8 years old. I'm not aware of any application that supports the problematic 1005 and/or 1015 but not the okay 1006. As such, I don't see any point in implementing support for the first two (although it should be very easy to implement them).

@egmontkob commented on GitHub (Jul 9, 2019): Did you mean 1005 between the application and conhost, or is that a typo in this picture? Mouse extensions 1005 and 1015 also exist but they are hardly used (if at all) due to their flaws, it's not something that applications are interested in. 1005 (xterm's two-byte UTF-8), 1015 (urxvt) and 1006 (xterm SGR), in this chronological order, are three mutually exclusive extensions to address the limitation of the column number. See e.g. Midnight Commander issues [2662](https://midnight-commander.org/ticket/2662) and [2956](https://midnight-commander.org/ticket/2956) for technical description about the flaws of the first two. Note that this story is now 6-8 years old. I'm not aware of any application that supports the problematic 1005 and/or 1015 but not the okay 1006. As such, I don't see any point in implementing support for the first two (although it should be very easy to implement them).
claunia commented 2026-01-30 22:04:43 +00:00
Author
Owner
Copy Link

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

That very well could be a typo, right now, conhost actually supports a bunch of different mouse modes, including, but not limited to 1005 and 1006.

@zadjii-msft commented on GitHub (Jul 9, 2019): That very well could be a typo, right now, conhost actually supports [a bunch of different mouse modes](https://github.com/microsoft/terminal/blob/master/src/terminal/adapter/DispatchTypes.hpp#L82-L86), including, but not limited to 1005 and 1006.
claunia commented 2026-01-30 22:04:44 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 9, 2019):

It’s not a typo. Sorry, this was intended to illustrate how the pseudoconsole system could support a bunch of mouse modes on the client end (an application requests 1005, 1015, legacy VT220, etc.) but present a unified mouse mode interface (1006) to the pty pipe holder.

@DHowett-MSFT commented on GitHub (Jul 9, 2019): It’s not a typo. Sorry, this was intended to illustrate how the pseudoconsole system could support a bunch of mouse modes on the client end (an application requests 1005, 1015, legacy VT220, etc.) but present a unified mouse mode interface (1006) to the pty pipe holder.
claunia commented 2026-01-30 22:04:44 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 9, 2019):

That diagram admittedly fits better in #376, which is the infrastructural part of this bug.

@DHowett-MSFT commented on GitHub (Jul 9, 2019): That diagram admittedly fits better in #376, which is the infrastructural part of this bug.
claunia commented 2026-01-30 22:04:44 +00:00
Author
Owner
Copy Link

@egmontkob commented on GitHub (Jul 9, 2019):

@DHowett-MSFT Awesome, thanks for the clarification!

@egmontkob commented on GitHub (Jul 9, 2019): @DHowett-MSFT Awesome, thanks for the clarification!
claunia commented 2026-01-30 22:04:45 +00:00
Author
Owner
Copy Link

@rcarmo commented on GitHub (Aug 3, 2019):

I'm eagerly awaiting this to show up in a future release - I keep clicking on tmux panes in hopes the mouse will work :)

@rcarmo commented on GitHub (Aug 3, 2019): I'm eagerly awaiting this to show up in a future release - I keep clicking on tmux panes in hopes the mouse will work :)
claunia commented 2026-01-30 22:04:45 +00:00
Author
Owner
Copy Link

@sandric commented on GitHub (Dec 16, 2019):

Any progress on this?

@sandric commented on GitHub (Dec 16, 2019): Any progress on this?
claunia commented 2026-01-30 22:04:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 16, 2019):

@sandric Not particularly - when there's something of note to share, we'll make sure to post in this thread 😜

@carlos-zamora is starting this work this month (as you can see from the "assigned to" and "milestone" fields to the right). He's got a PR (#3963) out starting on work for #376, one of the prerequisites for this feature.

@zadjii-msft commented on GitHub (Dec 16, 2019): @sandric Not particularly - when there's something of note to share, we'll make sure to post in this thread 😜 @carlos-zamora is starting this work this month (as you can see from the "assigned to" and "milestone" fields to the right). He's got a PR (#3963) out starting on work for #376, one of the prerequisites for this feature.
claunia commented 2026-01-30 22:04:46 +00:00
Author
Owner
Copy Link

@fpqc commented on GitHub (Feb 16, 2020):

@zadjii-msft The PR you linked says it was merged Is that correct now?

@fpqc commented on GitHub (Feb 16, 2020): @zadjii-msft The PR you linked says it was merged Is that correct now?
claunia commented 2026-01-30 22:04:47 +00:00
Author
Owner
Copy Link

@tjhowse commented on GitHub (Feb 17, 2020):

Based on the comment in the release notes:

The pseudoconsole will now process mouse escapes, but it won't do much useful with them yet (#3963)

It seems not (yet). I'm staying tuned!

@tjhowse commented on GitHub (Feb 17, 2020): Based on the comment in the release notes: > The pseudoconsole will now process mouse escapes, but it won't do much useful with them yet (#3963) It seems not (yet). I'm staying tuned!
claunia commented 2026-01-30 22:04:47 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 18, 2020):

@fpqc yep, that's correct, that one PR was merged. From that discussion, there's still a bunch of work needed before this will work fully in the Terminal:

  • Conpty emits a [sequence] on entering any mouse mode to tell terminals that they should synthesize VT Mouse Mode input as SGR sequences (with hover, scroll, etc)
  • Conhost translates Mouse input into VT from both conpty and the HWND the same way
  • Terminal can consume [sequence] to synthesize VT mouse mode input

And then of course, this issue:

  • Terminal synthesizes mouse input sequences
@zadjii-msft commented on GitHub (Feb 18, 2020): @fpqc yep, that's correct, that one PR was merged. From that discussion, there's still a bunch of work needed before this will work fully in the Terminal: > * [ ] Conpty emits a [sequence] on entering any mouse mode to tell terminals that they should synthesize VT Mouse Mode input as SGR sequences (with hover, scroll, etc) > * [ ] Conhost translates Mouse input into VT from both conpty and the HWND the same way > * [ ] Terminal can consume [sequence] to synthesize VT mouse mode input And then of course, this issue: * [ ] Terminal synthesizes mouse input sequences
claunia commented 2026-01-30 22:04:47 +00:00
Author
Owner
Copy Link

@giggio commented on GitHub (Mar 17, 2020):

How do we copy the text when VT Mouse is enabled? I couldn't do it on Vim or Tmux.

@giggio commented on GitHub (Mar 17, 2020): How do we copy the text when VT Mouse is enabled? I couldn't do it on Vim or Tmux.
claunia commented 2026-01-30 22:04:47 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Mar 17, 2020):

Hold down shift to interact with the terminal itself instead of the application inside it.

@DHowett-MSFT commented on GitHub (Mar 17, 2020): Hold down shift to interact with the terminal itself instead of the application inside it.
claunia commented 2026-01-30 22:04:48 +00:00
Author
Owner
Copy Link

@PetterS commented on GitHub (Mar 17, 2020):

This is so great! When will we see a preview of this in the Store?

@PetterS commented on GitHub (Mar 17, 2020): This is so great! When will we see a preview of this in the Store?
claunia commented 2026-01-30 22:04:48 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Mar 17, 2020):

Stay tuned

@DHowett-MSFT commented on GitHub (Mar 17, 2020): Stay tuned
claunia commented 2026-01-30 22:04:48 +00:00
Author
Owner
Copy Link

@yveslange commented on GitHub (Mar 18, 2020):

Downloaded from the shop! The mouse is working great in VIM, htop and Tmux. Finally, time to move from all other WSL Terminal to the microsoft one ! Good job guys and thanks a lot !

PS: shift is working great too !

@yveslange commented on GitHub (Mar 18, 2020): Downloaded from the shop! The mouse is working great in VIM, htop and Tmux. Finally, time to move from all other WSL Terminal to the microsoft one ! Good job guys and thanks a lot ! PS: shift is working great too !
claunia commented 2026-01-30 22:04:49 +00:00
Author
Owner
Copy Link

@jsbarrett commented on GitHub (Mar 21, 2020):

Just came here looking for why mouse wasn't working ... read the most recent comment from @yveslange and then updated the app ... and now mouse works perfect.

Thanks guys!

@jsbarrett commented on GitHub (Mar 21, 2020): Just came here looking for why mouse wasn't working ... read the most recent comment from @yveslange and then updated the app ... and now mouse works perfect. Thanks guys!
claunia commented 2026-01-30 22:04:50 +00:00
Author
Owner
Copy Link

@nicolus commented on GitHub (Mar 29, 2020):

@DHowett-MSFT : Mouse still doesn't work for me with Micro (https://github.com/zyedidia/micro), whereas both mouse and scrollwheel work flawlessly in the default powershell or cmd.exe terminal. Is mouse support only working in WSL for now ?

@nicolus commented on GitHub (Mar 29, 2020): @DHowett-MSFT : Mouse still doesn't work for me with Micro (https://github.com/zyedidia/micro), whereas both mouse and scrollwheel work flawlessly in the default powershell or cmd.exe terminal. Is mouse support only working in WSL for now ?
claunia commented 2026-01-30 22:04:50 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 30, 2020):

@nicolus indeed, mouse input only works for WSL applications currently. If you're using the Win32 version of micro, I'd bet that it won't work quite yet. You could probably work around this by running the WSL version for now. #376 is the issue we're using for the Windows mouse input

@zadjii-msft commented on GitHub (Mar 30, 2020): @nicolus indeed, mouse input only works for WSL applications currently. If you're using the Win32 version of micro, I'd bet that it won't work quite yet. You could probably work around this by running the WSL version for now. #376 is the issue we're using for the Windows mouse input
claunia commented 2026-01-30 22:04:51 +00:00
Author
Owner
Copy Link

@CodeMonkey90 commented on GitHub (May 11, 2020):

@zadjii-msft
Mouse events don't work for me with a custom profile with "commandline": "ssh [...]". Is this also expected until #376 is resolved? Is there a good workaround?

Edit: Or is that just a result of PowerShell/Win32-OpenSSH#1310 and would work otherwise?

@CodeMonkey90 commented on GitHub (May 11, 2020): @zadjii-msft Mouse events don't work for me with a custom profile with `"commandline": "ssh [...]"`. Is this also expected until #376 is resolved? Is there a good workaround? **Edit**: Or is that just a result of PowerShell/Win32-OpenSSH#1310 and would work otherwise?
claunia commented 2026-01-30 22:04:52 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 11, 2020):

This is a result of https://github.com/PowerShell/Win32-OpenSSH/issues/1310, which is (mercifully) fixed in the 8.x series.

@DHowett-MSFT commented on GitHub (May 11, 2020): This is a result of https://github.com/PowerShell/Win32-OpenSSH/issues/1310, which is (mercifully) fixed in the 8.x series.
claunia commented 2026-01-30 22:04:52 +00:00
Author
Owner
Copy Link

@CodeMonkey90 commented on GitHub (May 11, 2020):

@DHowett-MSFT Thanks for the quick reply. In that case, is there a sane way to manually upgrade to a version with the fix right now or is it better to just wait?

@CodeMonkey90 commented on GitHub (May 11, 2020): @DHowett-MSFT Thanks for the quick reply. In that case, is there a sane way to manually upgrade to a version with the fix right now or is it better to just wait?
claunia commented 2026-01-30 22:04:53 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 11, 2020):

Sure, just download the latest release from their Releases page!

@DHowett-MSFT commented on GitHub (May 11, 2020): Sure, just download the latest release from their Releases page!
claunia commented 2026-01-30 22:04:54 +00:00
Author
Owner
Copy Link

@rfc805 commented on GitHub (Aug 9, 2021):

I don't see it here or in the documentation, but how do you turn this behavior off entirely? It's incredibly annoying for people who don't want to have mouse interactions pass through. Holding shift is not a good option.

@rfc805 commented on GitHub (Aug 9, 2021): I don't see it here or in the documentation, but how do you turn this behavior off entirely? It's incredibly annoying for people who don't want to have mouse interactions pass through. Holding shift is not a good option.
claunia commented 2026-01-30 22:04:54 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 9, 2021):

@rfc805 there isn't a setting to disable this entirely - I'm not sure I've heard anyone request that before. Typically this is something that's controlled per-client application on other platforms, within the app's own config. Is there some app (vim, tmux, etc) in particular that's requesting mouse mode that you can't disable mouse input for?

@zadjii-msft commented on GitHub (Aug 9, 2021): @rfc805 there isn't a setting to disable this entirely - I'm not sure I've heard anyone request that before. Typically this is something that's controlled per-client application on other platforms, within the app's own config. Is there some app (`vim`, `tmux`, etc) in particular that's requesting mouse mode that you can't disable mouse input for?
claunia commented 2026-01-30 22:04:55 +00:00
Author
Owner
Copy Link

@rfc805 commented on GitHub (Aug 9, 2021):

It's mostly vim (over ssh) but on a large variety of hosts which aren't related, which makes it non-trivial to globally disable in unlinked/unshared profiles across a few hundred different remote hosts. A lot of it involves copying data from those hosts across each other, or to other Windows apps, etc - so I find myself holding shift down my whole life if I use terminal instead of putty/mintty.

@rfc805 commented on GitHub (Aug 9, 2021): It's mostly vim (over ssh) but on a large variety of hosts which aren't related, which makes it non-trivial to globally disable in unlinked/unshared profiles across a few hundred different remote hosts. A lot of it involves copying data from those hosts across each other, or to other Windows apps, etc - so I find myself holding shift down my whole life if I use terminal instead of putty/mintty.
claunia commented 2026-01-30 22:04:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 9, 2021):

You know, this actually already is on the backlog. I'd go upvote #4875 ☺️

@zadjii-msft commented on GitHub (Aug 9, 2021): You know, this actually already _is_ on the backlog. I'd go upvote #4875 ☺️
claunia commented 2026-01-30 22:04:55 +00:00
Author
Owner
Copy Link

@paukul commented on GitHub (Aug 9, 2021):

@rfc805 :set mouse-=a in vim will disable the mouse support for vim and should work around your issue until #4875 is merged

@paukul commented on GitHub (Aug 9, 2021): @rfc805 `:set mouse-=a` in vim will disable the mouse support for vim and should work around your issue until #4875 is merged
claunia commented 2026-01-30 22:04:55 +00:00
Author
Owner
Copy Link

@rfc805 commented on GitHub (Aug 9, 2021):

Thanks - I do know how to do it each time, just overall a productivity killer if you work in a large environment with a profile you do not control.

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

No dependencies set.

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

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