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

Shift-click shouldn't extend the selection in VT mouse more #14888

New Issue
Closed
opened 2026-01-31 04:22:24 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 04:22:24 +00:00
Owner
Copy Link

Originally created by @angelog0 on GitHub (Aug 17, 2021).

Windows Terminal version (or Windows build number)

19043.1165

This occurs wit WT-1.9.1942.0 and both with Emacs-27-2 (nox) and NOX builds from master (Emacs28), i.e. running Emacs (from MSYS2 or WSL packages) in WT.

I added this to the init.el file:

(setq mouse-drag-copy-region t)

This means that selecting text double clicking with the mouse or dragging it [*] should copy the selection to the clipboard and it allows for pasting the selection in other apps.

This does not work when running Emacs, MSYS2 package or WSL builds, in WT.

It DOES WORK when running the same app from MinTTY (MSYS2 or WSL + Emacs nox).

BTW, it works also in Termux+Emacs nox on Android.

So the issue seems related to WT.

[*] Remember that when running Emacs in a terminal, you have to hold down the SHIFT key while clicking or dragging.

Originally created by @angelog0 on GitHub (Aug 17, 2021). ### Windows Terminal version (or Windows build number) 19043.1165 This occurs wit WT-1.9.1942.0 and both with Emacs-27-2 (nox) and NOX builds from master (Emacs28), i.e. running Emacs (from MSYS2 or WSL packages) in WT. I added this to the `init.el` file: ``` (setq mouse-drag-copy-region t) ``` This means that selecting text double clicking with the mouse or dragging it [*] should copy the selection to the clipboard and it allows for pasting the selection in other apps. This does not work when running Emacs, MSYS2 package or WSL builds, in WT. It DOES WORK when running the same app from MinTTY (MSYS2 or WSL + Emacs nox). BTW, it works also in Termux+Emacs nox on Android. So the issue seems related to WT. ----- [*] Remember that when running Emacs in a terminal, you have to hold down the SHIFT key while clicking or dragging.
claunia commented 2026-01-31 04:22:26 +00:00
Author
Owner
Copy Link

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

you have to hold down the SHIFT key while clicking or dragging.

Curious, I wasn't aware that there was any sort of input sequence that terminals send to client applications in this scenario to indicate "the user made a selection". I'd imagine that this functionality would only work with emacs's built-in selection handling, and not rely on the Terminal's selection.

@j4james any ideas on this one?

@zadjii-msft commented on GitHub (Aug 17, 2021): > you have to hold down the SHIFT key while clicking or dragging. Curious, I wasn't aware that there was any sort of input sequence that terminals send to client applications in this scenario to indicate "the user made a selection". I'd imagine that this functionality would only work with emacs's built-in selection handling, and not rely on the Terminal's selection. @j4james any ideas on this one?
claunia commented 2026-01-31 04:22:26 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 17, 2021):

This could be VT200 highlight tracking, perhaps...

@DHowett commented on GitHub (Aug 17, 2021): This could be VT200 highlight tracking, perhaps...
claunia commented 2026-01-31 04:22:26 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 17, 2021):

I have no idea. I also thought it might have been highlight tracking, but it doesn't look like Mintty supports that either, so I don't think it's that. Will require some digging to see what exactly emacs is doing.

@j4james commented on GitHub (Aug 17, 2021): I have no idea. I also thought it might have been highlight tracking, but it doesn't look like Mintty supports that either, so I don't think it's that. Will require some digging to see what exactly emacs is doing.
claunia commented 2026-01-31 04:22:27 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Aug 17, 2021):

Regarding the SHIFT key, see this from the Emacs manual.

@angelog0 commented on GitHub (Aug 17, 2021): Regarding the SHIFT key, see [this](https://www.gnu.org/software/emacs/manual/html_node/emacs/Text_002dOnly-Mouse.html) from the Emacs manual.
claunia commented 2026-01-31 04:22:27 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 17, 2021):

We may need a bit more of your init.el than that -- mouse-drag-copy-region on its own does not enable mouse support here with emacs-nox 26.1 Debian.

@DHowett commented on GitHub (Aug 17, 2021): We _may_ need a bit more of your `init.el` than that -- `mouse-drag-copy-region` on its own does not enable mouse support here with emacs-nox 26.1 Debian.
claunia commented 2026-01-31 04:22:27 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Aug 17, 2021):

OK, it seems that in WT I have to double click, holding down the SHIFT, the right mouse button (mouse-3 in Emacs jargon) to get the pasting... Usually in WT the pasting occurs just with a single click of the mouse-3.

BTW, can I reconfigure WT to use mouse-2 (the wheel) clicks to paste? This occurs in MinTTY and other GNU/Linux terminals...

@angelog0 commented on GitHub (Aug 17, 2021): OK, it seems that in WT I have to _double click_, holding down the SHIFT, the right mouse button (mouse-3 in Emacs jargon) to get the pasting... Usually in WT the pasting occurs just with a single click of the mouse-3. BTW, can I reconfigure WT to use mouse-2 (the wheel) clicks to paste? This occurs in MinTTY and other GNU/Linux terminals...
claunia commented 2026-01-31 04:22:27 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Aug 17, 2021):

Maybe do you mean this:

(require 'mouse)                                                                    
(require 'mwheel)                                                                  
(unless window-system                                                               
  (xterm-mouse-mode t)                                                              
  (mouse-wheel-mode t))

(setq mouse-drag-copy-region t)

To select the above text I had to run WSL-Emacs-nox from a MinTTY terminal, dragging the mouse holding SHIFT down and then using CTRL-v here. The same steps from WT did not work.

@angelog0 commented on GitHub (Aug 17, 2021): Maybe do you mean this: ``` (require 'mouse) (require 'mwheel) (unless window-system (xterm-mouse-mode t) (mouse-wheel-mode t)) (setq mouse-drag-copy-region t) ``` To select the above text I had to run WSL-Emacs-nox from a MinTTY terminal, dragging the mouse holding SHIFT down and then using CTRL-v here. The same steps from WT did not work.
claunia commented 2026-01-31 04:22:28 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 19, 2021):

OK, I've had a chance to play in Emacs now and I think I know what's going on. But I don't think it really has anything to do with Emacs.

Basically when app has enabled one of the mouse modes and is intercepting mouse clicks, the terminal obviously loses the ability to use the mouse in the way it usually would (e.g. selecting text and copying it to the clipboard). But if you're holding down shift when you click, those clicks don't get converted to escape sequences, so they'll still be handled by the terminal.

But the problem is that shift-clicking typically means you want to extend the selection, rather than starting a new one, which makes it somewhat difficult to use. As a workaround for this, Mintty seems to disable that shift functionality when an app has enabled mouse mode, which I think is probably a reasonable approach to take - I don't know if that's common behaviour in other terminals though.

The other problem is that auto-copying doesn't seem to be working at all (nothing to do with mouse modes). I'm not sure if this is expected or not, but I thought the "Automatically copy selection to clipboard" option would mean any text that was selected would automatically be copied to the clipboard, but that doesn't seem to be the case - I have to right click to copy. I've only looked briefly, but I didn't see an existing issue for this.

Edit: Auto-copying is actually working fine. I was looking at the settings in the wrong terminal. 🤦‍♂️

@j4james commented on GitHub (Aug 19, 2021): OK, I've had a chance to play in Emacs now and I think I know what's going on. But I don't think it really has anything to do with Emacs. Basically when app has enabled one of the mouse modes and is intercepting mouse clicks, the terminal obviously loses the ability to use the mouse in the way it usually would (e.g. selecting text and copying it to the clipboard). But if you're holding down shift when you click, those clicks _don't_ get converted to escape sequences, so they'll still be handled by the terminal. But the problem is that shift-clicking typically means you want to extend the selection, rather than starting a new one, which makes it somewhat difficult to use. As a workaround for this, Mintty seems to disable that shift functionality when an app has enabled mouse mode, which I think is probably a reasonable approach to take - I don't know if that's common behaviour in other terminals though. <s>The other problem is that auto-copying doesn't seem to be working at all (nothing to do with mouse modes). I'm not sure if this is expected or not, but I thought the "Automatically copy selection to clipboard" option would mean any text that was selected would automatically be copied to the clipboard, but that doesn't seem to be the case - I have to right click to copy. I've only looked briefly, but I didn't see an existing issue for this.</s> Edit: Auto-copying is actually working fine. I was looking at the settings in the wrong terminal. 🤦‍♂️
claunia commented 2026-01-31 04:22:28 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 19, 2021):

I've tried a few other terminals now, and not everyone supports extending a selection with shift-click, but those that do, seem to follow the same behaviour as Mintty, i.e. they disable extended selections when an app has enabled a mouse mode. That way you can use shift-click to get the equivalent of a regular click that will be handled by the terminal.

The terminals I've seen with this behavior include Gnome Terminal, Konsole, and Rxvt.

@j4james commented on GitHub (Aug 19, 2021): I've tried a few other terminals now, and not everyone supports extending a selection with shift-click, but those that do, seem to follow the same behaviour as Mintty, i.e. they disable extended selections when an app has enabled a mouse mode. That way you can use shift-click to get the equivalent of a regular click that will be handled by the terminal. The terminals I've seen with this behavior include Gnome Terminal, Konsole, and Rxvt.
claunia commented 2026-01-31 04:22:28 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 8, 2022):

Wait after having re-read this yesterday, is this the same thing as #9608?

@zadjii-msft commented on GitHub (Nov 8, 2022): Wait after having re-read this yesterday, is this the same thing as #9608?
claunia commented 2026-01-31 04:22:28 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 8, 2022):

Yeah, I think so.

@j4james commented on GitHub (Nov 8, 2022): Yeah, I think so.
claunia commented 2026-01-31 04:22:28 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 8, 2022):

/dup #9608

Thanks for the sanity check!

@zadjii-msft commented on GitHub (Nov 8, 2022): /dup #9608 Thanks for the sanity check!
claunia commented 2026-01-31 04:22:29 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Nov 8, 2022):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Nov 8, 2022): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
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-TerminalControl Issue-Bug Needs-Tag-Fix Product-Terminal Resolution-Duplicate
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#14888
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?