Skip to content

Shift modifer conficts between "disable mouse input" and "extend selection" #9608

New issue
New issue
Closed
#19973
Closed
Shift modifer conficts between "disable mouse input" and "extend selection"#9608
#19973
Labels
Area-InputRelated to input processing (key presses, mouse, etc.)Area-TerminalControlIssues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.)In-PRThis issue has a related PRIssue-TaskIt's a feature request, but it doesn't really need a major design.Needs-Tag-FixDoesn't match tag requirementsProduct-TerminalThe new Windows Terminal.
Milestone
Backlog

Description

@danfoster
Dan Foster (danfoster)
opened on Mar 24, 2021

Windows Terminal version (or Windows build number)

1.6.10571

Other Software

tmux 3.0a

Steps to reproduce

In Windows terminal, if you have an existing selection and then make a new selection while the shift key is held, the beginning of the selection is not changed, but instead of the selection is extended.

If you are using an application that supports mouse input (tmux in my example, but this should hold true for any application that supports mouse input), you have to hold the shift key to disable mouse input so you can natively select text in the terminal.

These 2 features conflict with each other as they are on the same modifier key (shift).

A common pattern for me in tmux, is I want to highlight some text, so I shift+select, but I miss my desired start of the selection, so I attempt to shift+select again, but due to the "extend select" feature, it doesn't move my starting position.
There is no-way I can find to clear the current selection using the mouse. My only workaround is to type a character and delete it again to clear my selection.

Expected Behavior

I would like to see a way to disable the "extend select" feature, or move it to a different modifier key, so it doesn't conflict.

Actual Behavior

See Steps to reproduce

Activity

  1. ghost added
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Mar 24, 2021
  2. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on Mar 24, 2021

  3. DHowett commented on Mar 24, 2021

    @DHowett
    Dustin L. Howett (DHowett)
    on Mar 24, 2021
    Member

    The solution we took for 1.7 is that Shift-clicking when there's no selection sets the selection start point. Is that an acceptable compromise?

  4. DHowett commented on Mar 24, 2021

    @DHowett
    Dustin L. Howett (DHowett)
    on Mar 24, 2021
    Member

    (with esc for dismissing the selection- sorry; I didn't consider all of the issues there)

  5. danfoster commented on Mar 24, 2021

    @danfoster
    Dan Foster (danfoster)
    on Mar 24, 2021
    Author

    It's not ideal imo, as this differs from the behavior of terminal emulators on different OSes, which makes moving between platforms and muscle memory conflict.
    My preference would be that there is some method of making shift+click always start a new selection, but I do realise it's subjective at this point.

  6. Don-Vito commented on Apr 11, 2021

    @Don-Vito
    Don-Vito
    on Apr 11, 2021
    Contributor

    Dustin L. Howett (@DHowett), Dan Foster (@danfoster) - some terminals dismiss selection with shift click on the selection boundaries (anchor / end). We can easily implement. WDYT?

  7. DHowett commented on Apr 12, 2021

    @DHowett
    Dustin L. Howett (DHowett)
    on Apr 12, 2021
    Member

    I don't mind that, yeah

  8. YAMLcase commented on Apr 14, 2021

    @YAMLcase
    YAMLcase (YAMLcase)
    on Apr 14, 2021

    I'm not sure trying to get mouse event override and extend selection to co-exist is the best approach as even long standing terminal apps struggle with this clash.

    putty for instance has options to have the mouse behave like windows or xterm (or a mix of the two). I for one have never once used shift to extend my selection, I just reselect if I'm not satisfied... however I also wouldn't presume anyone else to use my workflow.

    image

    Perhaps the way to go is add a suite of options to let people decide on their own with some reasonable defaults. Here's some ideas:

    • extend selection modifier key (shift, ctrl, alt, disabled)
    • mouse event override modifier key (shift, ctrl, alt, disabled)

    FYI, more behaviors affected by this are shift + double and triple clicking won't select the entire word/line, it only selects from the beginning of the word/line to the character you're clicking on

  9. zadjii-msft commented on Feb 25, 2022

    @zadjii-msft
    Mike Griese (zadjii-msft)
    on Feb 25, 2022
    Member

    Hmm. Here's a thought: the selection anchors from #10865, we could make those draggable with the mouse even in mouse mode. Then you could just move the start anchor manually, even without shift.

    Big picture there's also #1553 for more elaborate settings for mouse bindings.

  10. Mike Griese (zadjii-msft)
    added
    Area-InputRelated to input processing (key presses, mouse, etc.)
    Area-TerminalControlIssues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.)
    Issue-TaskIt's a feature request, but it doesn't really need a major design.
    Product-TerminalThe new Windows Terminal.
    and removed
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Feb 25, 2022
  11. ghost removed
    Needs-Tag-FixDoesn't match tag requirements
    on Feb 25, 2022
  12. Mike Griese (zadjii-msft)
    added this to the Backlog milestone on Feb 25, 2022

  13. DHowett commented on Oct 1, 2025

    @DHowett
    Dustin L. Howett (DHowett)
    on Oct 1, 2025
    Member

    Copying Josef Wells (@josefwells)' request from #19321

    Description of the new feature

    Other terminal tools, specifically wsltty/mintty allow you to change the modifier between shift/ctrl/alt/win/off and also to invert the sense by changing the default click target between window/application.

    Image This would make using windows terminal (specifically WSL) with tmux more natural and more like a native linux environment (copy with highlight, paste with right-click.. not additional modifiers needed).

    Proposed technical implementation details

    No response

  14. Dustin L. Howett (DHowett)
    marked Allow changing default click target from window<->application #19321 as a duplicate of this issue on Oct 1, 2025
  15. microsoft-github-policy-service
    unmarked Allow changing default click target from window<->application #19321 as a duplicate of this issue on Oct 1, 2025
  16. microsoft-github-policy-service
    added
    In-PRThis issue has a related PR
    on Mar 13, 2026
  17. Dustin L. Howett (DHowett)
    closed this as completedin #19973on Mar 17, 2026
  18. microsoft-github-policy-service
    added
    Needs-Tag-FixDoesn't match tag requirements
    on Mar 17, 2026
  19. pull
    added a commit that references this issue on Mar 17, 2026

    Improve UX for selection during VTMM (microsoft#19973)

    2e33056
  20. Dustin L. Howett (DHowett)
    added a commit that references this issue on Apr 3, 2026

    Improve UX for selection during VTMM (#19973)

    e382d32
  21. Dustin L. Howett (DHowett)
    added a commit that references this issue on Apr 30, 2026

    Improve UX for selection during VTMM (#19973)

    8140092

  22. Slimariella commented on Jun 18, 2026

    @Slimariella
    Slimariella
    on Jun 18, 2026

    Workaround: keep native WT selection and mouse-wheel scroll in tmux — without Shift

    The Shift conflict in this issue comes from a single constraint: the mouse is one signal. With tmux mouse on, tmux owns drag + wheel, so native WT selection requires holding Shift. With tmux mouse off, WT handles selection natively, but the wheel just becomes ↑/↓ arrows (alternate-scroll) and stops scrolling the pane.

    Instead of trying to split the mouse inside the terminal (which WT can't do today), you can split it one layer up, at the OS input level, with AutoHotkey v2 — and only while Terminal is focused:

    #Requires AutoHotkey v2.0
#HotIf WinActive("ahk_exe WindowsTerminal.exe")
WheelUp::Send("+{PgUp}")
WheelDown::Send("+{PgDn}")
#HotIf

    Then keep tmux in mouse off (native WT selection + right-click copy/paste preserved) and bind those keys to scroll the pane:

    set -g mouse off
bind -n S-PageUp   copy-mode -e \; send-keys -X -N 3 scroll-up
bind -n S-PageDown send-keys -X -N 3 scroll-down

    Result: the physical wheel scrolls the tmux scrollback, drag still produces the native blue selection, and Shift is never needed. Adjust -N 3 for scroll speed.

    Full snippet (AHK script + tmux.conf + README) as a gist: https://gist.github.com/Slimariella/6fc293e1350132cad1826b1492f30460

    Tested on Windows Terminal 1.24 + tmux 3.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-InputRelated to input processing (key presses, mouse, etc.)Area-TerminalControlIssues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.)In-PRThis issue has a related PRIssue-TaskIt's a feature request, but it doesn't really need a major design.Needs-Tag-FixDoesn't match tag requirementsProduct-TerminalThe new Windows Terminal.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions