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

Remember mouse selection mode when extending #23240

New Issue
Closed
opened 2026-01-31 08:36:21 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 08:36:21 +00:00
Owner
Copy Link

Originally created by @elibarzilay on GitHub (May 10, 2025).

Description of the new feature

This is another suggested feature which is inspired by how my xterm works (but actually many editors including notepad, vscode, and my browser (edge) do the same): it would be nice if the selection mode (char/word/line) was remembered and used when extending the selection.

For example, if I double-click+drag to select a few words, and then shift-click elsewhere in the middle of a word, the final selection would be as if I originally dragged to the second location, which would select up to the whole word.

Proposed technical implementation details

Keep a global state for the selection mode, set it when starting a selection, use it when extending it.

The tricky bit is what happens when using multiple clicks on an extended shift-selection. Existing things I tried have different opinions:

  • Edge ignores it, so same selection mode is always used.
  • Xterm/vscode will change the current selection mode to word/line on a shifted double/triple-click.
  • Notepad behaves as if the shifted click is starting a new selection.
Originally created by @elibarzilay on GitHub (May 10, 2025). ### Description of the new feature This is another suggested feature which is inspired by how my `xterm` works (but actually many editors including notepad, vscode, and my browser (edge) do the same): it would be nice if the selection mode (char/word/line) was remembered and used when extending the selection. For example, if I double-click+drag to select a few words, and then shift-click elsewhere in the middle of a word, the final selection would be as if I originally dragged to the second location, which would select up to the whole word. ### Proposed technical implementation details Keep a global state for the selection mode, set it when starting a selection, use it when extending it. The tricky bit is what happens when using multiple clicks on an extended shift-selection. Existing things I tried have different opinions: * Edge ignores it, so same selection mode is always used. * Xterm/vscode will change the current selection mode to word/line on a shifted double/triple-click. * Notepad behaves as if the shifted click is starting a new selection.
claunia added the Needs-TriageIssue-TaskPriority-3Needs-Tag-FixArea-UserInterface labels 2026-01-31 08:36:22 +00:00
claunia commented 2026-01-31 08:36:24 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 14, 2025):

Thanks for the request!

I tried to reproduce your reported behavior in xterm (372), but I was unable to do so. When I shift-click it discards the entire selection no matter how I'd started it.

VSCode seems to have a slightly more complex model: double-click shift-click retains wordwise selection unless it is moving the selection endpoint back inside the selected region, at which point it becomes character selection.

For Edge it looks like you're right, except that selections can be promoted to linewise selections with shift-triple-click, but that also blows away the original selection.

Notepad seems to differ based on whether it's modern notepad or original notepad.

gnome-terminal operates for wordwise selection like Edge does for linewise: if you shift-double-click it creates a new selection. But it does expand in the way you're asking us to expand.

I'm on the fence. In general, I'd prefer to keep the selection behavior consistent with prior versions of Terminal. It has a simplicity to it: right now, the only thing you need to keep in mind when expanding a selection is the number of clicks in the current event. That means that whether or not Shift is pressed, it's one click for a character, two for a word and three for a line. But I could probably be persuaded...

This gets slightly more complicated and annoying (and a change here perhaps amplified) when you have mouse mode in the mix (where Shift simultaneously means Expand Selection and Actually Do Selection.)

@DHowett commented on GitHub (May 14, 2025): Thanks for the request! I tried to reproduce your reported behavior in xterm (372), but I was unable to do so. When I shift-click it discards the entire selection no matter how I'd started it. VSCode seems to have a slightly more complex model: double-click shift-click retains wordwise selection _unless it is moving the selection endpoint back inside the selected region_, at which point it becomes character selection. For Edge it looks like you're right, except that selections can be promoted to linewise selections with shift-triple-click, but that also blows away the _original_ selection. Notepad seems to differ based on whether it's modern notepad or original notepad. gnome-terminal operates for wordwise selection like Edge does for linewise: if you shift-double-click it creates a new selection. But it does expand in the way you're asking us to expand. I'm on the fence. _In general,_ I'd prefer to keep the selection behavior consistent with prior versions of Terminal. It has a simplicity to it: right now, the only thing you need to keep in mind when expanding a selection is the _number of clicks in the current event._ That means that whether or not <kbd>Shift</kbd> is pressed, it's one click for a character, two for a word and three for a line. But I could probably be persuaded... This gets slightly more complicated and annoying (and a change here perhaps amplified) when you have mouse mode in the mix (where <kbd>Shift</kbd> simultaneously means Expand Selection and Actually Do Selection.)
claunia commented 2026-01-31 08:36:25 +00:00
Author
Owner
Copy Link

@ebarzilay-godaddy commented on GitHub (May 16, 2025):

  • xterm: I don't even remember what's the original way to extend a selection, I made it do the obvious thing a long time ago. If you really want to try it, I'm including the relevant config at the end.

  • VSCode: yeah, I didn't went to the details of clicking inside the selection to keep it short (and also because that's less important, IMO).

  • Edge: I'm guessing that you tried clicking on text --- when doing that in an editable textarea it behaves in the more common way and doesn't blows away the current selection.

  • Sidenote: not sure what's "mouse mode", but I do use copyOnSelect: true.

In any case, the simplicity you're talking about is there, but at least my experience is that it confused me many times, and worse: my confusion just made me manually find the beginning of the line and single click that and then look for the end (possibly because this almost always happens when I'm staring at a wall of logs, so I'm heavily distracted).

I finally took the time to document that, and look into why I get confused (realizing that most editors do what I expect), and then filed this since it seems useful. If the current behavior is known and preferred, then I'll concede and hope to remember it next time I run into it...

To configure xterm to extend the selection on S-click:

*VT100*translations: #override \
  <Btn1Up>:                     select-end(PRIMARY,CLIPBOARD) \n\
  Shift ~Ctrl ~Meta <Btn1Down>: start-extend() \n

This is normally put in a ~/.Xdefaults or ~/.Xresources, and to make sure that it takes effect, you run xrdb -load <the-file>. (Note the syntax peculiarities: the mixture of backslashes and \ns is not a typo.)

This should do the trick, but I'm guessing that it's not too important, so I'll leave it at that. If it is, then I can include a recording or provide a more complete setup.

@ebarzilay-godaddy commented on GitHub (May 16, 2025): * xterm: I don't even remember what's the original way to extend a selection, I made it do the obvious thing a long time ago. If you really want to try it, I'm including the relevant config at the end. * VSCode: yeah, I didn't went to the details of clicking inside the selection to keep it short (and also because that's less important, IMO). * Edge: I'm guessing that you tried clicking on text --- when doing that in an editable textarea it behaves in the more common way and doesn't blows away the current selection. * Sidenote: not sure what's "mouse mode", but I do use `copyOnSelect: true`. In any case, the simplicity you're talking about is there, but at least my experience is that it confused me many times, and worse: my confusion just made me manually find the beginning of the line and single click that and then look for the end (possibly because this almost always happens when I'm staring at a wall of logs, so I'm heavily distracted). I finally took the time to document that, and look into why I get confused (realizing that most editors do what I expect), and then filed this since it seems useful. If the current behavior is known and preferred, then I'll concede and hope to remember it next time I run into it... --- To configure xterm to extend the selection on S-click: ``` *VT100*translations: #override \ <Btn1Up>: select-end(PRIMARY,CLIPBOARD) \n\ Shift ~Ctrl ~Meta <Btn1Down>: start-extend() \n ``` This is normally put in a `~/.Xdefaults` or `~/.Xresources`, and to make sure that it takes effect, you run `xrdb -load <the-file>`. (Note the syntax peculiarities: the mixture of backslashes and `\n`s is not a typo.) This should do the trick, but I'm guessing that it's not too important, so I'll leave it at that. If it is, then I can include a recording or provide a more complete setup.
claunia commented 2026-01-31 08:36:25 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 28, 2025):

This is something we might be willing to revisit once we have #1553 (pointer bindings,) but I'm not ready to commit to it just yet. 🙂

Thanks for digging up your xterm config, though!

@DHowett commented on GitHub (May 28, 2025): This is something we _might_ be willing to revisit once we have #1553 (pointer bindings,) but I'm not ready to commit to it just yet. 🙂 Thanks for digging up your xterm config, though!
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-UserInterface Issue-Task Needs-Tag-Fix Needs-Triage Priority-3
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#23240
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?