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

Multiple sets of word delimiters for double-click selection #9991

New Issue
Open
opened 2026-01-31 02:09:34 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 02:09:34 +00:00
Owner
Copy Link

Originally created by @rbaradari on GitHub (Aug 4, 2020).

Description of the new feature/enhancement

Currently, users can configure a single set of word delimiters (wordDelimiters) to be used for word boundary detection.
Depending on the context users need different sets of word delimiters.

For example (>< marks the double-click selection)

  • selecting a full path Text before >/home/user-name/file< text after
  • selecting a directory Text before /home/>user-name</file text after

Having a possibility to define multiple sets of word delimiters and to dynamically switch between them would support the user in quickly selecting what he intends to.

Proposed technical implementation details

Assuming that multiple sets of word delimiters could be defined then one possibility to provide a dynamic selection would be to use CTRL and ALT to toggle between the sets.
This way a user could double-click for the standard word delimiter selection, ALT-double-click for a set that only breaks on spaces to select full paths and CTRL-double-click to select path elements by using a set that breaks only on slash.

Originally created by @rbaradari on GitHub (Aug 4, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> Currently, users can configure a single set of word delimiters (`wordDelimiters`) to be used for word boundary detection. Depending on the context users need different sets of word delimiters. For example (`><` marks the double-click selection) * selecting a full path `Text before >/home/user-name/file< text after` * selecting a directory `Text before /home/>user-name</file text after` Having a possibility to define multiple sets of word delimiters and to dynamically switch between them would support the user in quickly selecting what he intends to. # Proposed technical implementation details <!-- A clear and concise description of what you want to happen. --> Assuming that multiple sets of word delimiters could be defined then one possibility to provide a dynamic selection would be to use CTRL and ALT to toggle between the sets. This way a user could double-click for the standard word delimiter selection, ALT-double-click for a set that only breaks on spaces to select full paths and CTRL-double-click to select path elements by using a set that breaks only on slash.
claunia added the Issue-FeatureArea-SettingsProduct-Terminal labels 2026-01-31 02:09:34 +00:00
claunia commented 2026-01-31 02:09:35 +00:00
Author
Owner
Copy Link

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

This isn't the craziest request I've heard - I'll tag this up as a part of "mouse bindings" in general. Thanks!

@zadjii-msft commented on GitHub (Aug 4, 2020): This isn't the craziest request I've heard - I'll tag this up as a part of "mouse bindings" in general. Thanks!
claunia commented 2026-01-31 02:09:35 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Aug 4, 2020):

On a related note…
mintty in Git Bash has asymmetric word delimiters for double-click selection.

Assuming there is abc:def:ghi:jkl on the screen:

  • If I double-click e, then it selects abc:def.
  • If I double-click g, then it selects abc:def:ghi.
  • If I double-click the colon between f and g, then it selects abc:def:.

I'm not currently requesting that feature, just wanted to mention it.

@KalleOlaviNiemitalo commented on GitHub (Aug 4, 2020): On a related note… mintty in Git Bash has asymmetric word delimiters for double-click selection. Assuming there is `abc:def:ghi:jkl` on the screen: - If I double-click `e`, then it selects `abc:def`. - If I double-click `g`, then it selects `abc:def:ghi`. - If I double-click the colon between `f` and `g`, then it selects `abc:def:`. I'm not currently requesting that feature, just wanted to mention it.
claunia commented 2026-01-31 02:09:35 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 6, 2020):

Huh, that's really interesting. So, we're almost set up for something like this. We followed PuTTY's system of "character classes"[1], which if we exposed would allow users to configure different levels of delimiters. Perhaps the right way to model this is... (open to discussion, I am not making a ruling here 😄)

[1] a "word" is actually a contiguous region of codepoints in the same class! thanks @carlos-zamora!

class characters
0 space (always its own class)
1 all other word delimiters
2 things that might exist in paths
3 normal characters

perhaps multiple-click could just be a class delta transition -- double-click is "select codepoints where Δ(class) <= 0", triple-click is "select codepoints where Δ(class) <= 1" and so on.

This would mean that triple-click would be required to select the classes "[normal characters] + [things that might exist in paths]" where double-click would still select all "[normal characters]"?

Thoughts? Is this way off-base, undiscoverable, or something?

@DHowett commented on GitHub (Aug 6, 2020): Huh, that's really interesting. So, we're _almost_ set up for something like this. We followed PuTTY's system of "character classes"[1], which if we exposed would allow users to configure different _levels_ of delimiters. Perhaps the right way to model this is... (open to discussion, I am not making a ruling here :smile:) [1] a "word" is actually a contiguous region of codepoints in the same class! thanks @carlos-zamora! class|characters -|- 0|space (always its own class) 1|all other word delimiters 2|things that might exist in paths 3|normal characters perhaps multiple-click could just be a class delta transition -- double-click is "select codepoints where `Δ(class) <= 0`", triple-click is "select codepoints where `Δ(class) <= 1`" and so on. This would mean that triple-click would be required to select the classes "[normal characters] + [things that might exist in paths]" where double-click would still select all "[normal characters]"? Thoughts? Is this way off-base, undiscoverable, or something?
claunia commented 2026-01-31 02:09:35 +00:00
Author
Owner
Copy Link

@rbaradari commented on GitHub (Aug 6, 2020):

As a user I wouldn't mind a double-click vs. triple-click differentiation or even a double-click on an existing selection to expand it. All versions, including the modifiers I proposed, are similarly hard to discover.

BTW: While reading up on the PuTTY docs I realized that ALT is already connected to rectangular selection and using ALT to toggle word delimiters for double-click selection might be misleading. This leaves only CTRL for this solution.

@rbaradari commented on GitHub (Aug 6, 2020): As a user I wouldn't mind a double-click vs. triple-click differentiation or even a double-click on an existing selection to expand it. All versions, including the modifiers I proposed, are similarly hard to discover. BTW: While reading up on the PuTTY docs I realized that ALT is already connected to rectangular selection and using ALT to toggle word delimiters for double-click selection might be misleading. This leaves only CTRL for this solution.
claunia commented 2026-01-31 02:09:36 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Aug 6, 2020):

I don't think it would be too confusing if Alt+single-click selects a rectangle but Alt+double-click selects words with alternative word boundaries.

However, if the user has already selected some words and then extends the selection with Alt+Shift+double-click, and the first click makes the selection rectangular but the second click makes it word-based again, then that will look odd.

@KalleOlaviNiemitalo commented on GitHub (Aug 6, 2020): I don't think it would be too confusing if Alt+single-click selects a rectangle but Alt+double-click selects words with alternative word boundaries. However, if the user has already selected some words and then extends the selection with Alt+Shift+double-click, and the first click makes the selection rectangular but the second click makes it word-based again, then that will look odd.
claunia commented 2026-01-31 02:09:36 +00:00
Author
Owner
Copy Link

@simonratner commented on GitHub (Aug 15, 2020):

Triple-click selects a line / paragraph in line-based / flow-based layouts respectively — very common shortcut shared by a lot of software. I think it might be ok if triple-click on a path selected the path instead, and an additional click was required to expand to the rest of the line, but making that behaviour non-surprising would be hard, especially given that multi-click chords rely heavily on muscle memory: you can't exactly "see" the result and just add an extra click. Also, requiring 5 clicks to select a line (with the 4 classes listed above) is silly territory. Perhaps if it auto-skipped through classes that would not change the selection?

A modifier key is more consistent in any case I think.

There is also #574, and the possibility of tying smart double-click selection to it (double-click on an identified path/url selects the path instead of a single word, but in all other contexts continues to work as it does today).

@simonratner commented on GitHub (Aug 15, 2020): Triple-click selects a line / paragraph in line-based / flow-based layouts respectively — very common shortcut shared by a lot of software. I think it _might_ be ok if triple-click on a path selected the path instead, and an additional click was required to expand to the rest of the line, but making that behaviour non-surprising would be hard, especially given that multi-click chords rely heavily on muscle memory: you can't exactly "see" the result and just add an extra click. Also, requiring 5 clicks to select a line (with the 4 classes listed above) is silly territory. Perhaps if it auto-skipped through classes that would not change the selection? A modifier key is more consistent in any case I think. There is also #574, and the possibility of tying smart double-click selection to it (double-click on an identified path/url selects the path instead of a single word, but in all other contexts continues to work as it does today).
claunia commented 2026-01-31 02:09:36 +00:00
Author
Owner
Copy Link

@phealy commented on GitHub (Aug 24, 2020):

#3196 would resolve a lot of this ask as well. I suggested there implementing it on a quadruple-click instead of modifying existing behavior or using a modifier, but it could also be a bound action on a modifier key as well.

@phealy commented on GitHub (Aug 24, 2020): #3196 would resolve a lot of this ask as well. I suggested there implementing it on a quadruple-click instead of modifying existing behavior or using a modifier, but it could also be a bound action on a modifier key as well.
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-Settings Issue-Feature Product-Terminal
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#9991
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?