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

Starting point for copy selection remains anchored when using a mouse-aware application #15308

New Issue
Open
opened 2026-01-31 04:34:36 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 04:34:36 +00:00
Owner
Copy Link

Originally created by @penguin359 on GitHub (Sep 22, 2021).

Windows Terminal version (or Windows build number)

1.10.2383.0

Other Software

vim 8.1 (inside WSL with mouse support)
tmux 3.0a (inside WSL with mouse support)

Steps to reproduce

This issue can be produced with either Vim or Tmux. With vim, do the following:

  1. Open any file in Vim.
    $ vim ~/.bashrc
  2. Enable mouse support.
    :set ttymouse=xterm2
    :set mouse=a
  3. At this point, regular mouse events go to the app. However, if I want to use Windows Terminal to copy/paste something, I can hold down Shift when using the mouse. Highlight some word on the screen.
  4. Try highlighting a different word/line instead.

The same can be replicated in Tmux:

  1. Open tmux
    $ tmux new
  2. Enable mouse support
    Ctrl-b :
    set -g -q mouse on
  3. Proceed the same as step 3 above.

Expected Behavior

I am expecting for Shift to allow me to send mouse events to Windows Terminal and have it act the same as if I was using the mouse normally, but without a mouse-aware terminal program. I am looking for a way have a mouse-aware terminal app running, but still have the option to use the Windows Terminal's mouse support for copy/pasting text as needed.

I spend most of my time inside tmux using multiple panes and heavy use of it's mouse support to switch panes, but still need to access Windows Terminal for certain copy/paste operations.

Other terminal apps that do the expected behavior include PuTTY on Windows with it's interaction with Shift allowing me to control PuTTY instead of sending the mouse event to tmux/vim and Gnome Terminal on Linux though it uses Control for the same purpose. I believe iTerm2 on macOS also implements this behavior, but with Alt. I have not found any modified key for Windows Terminal that allows me to use the mouse unencumbered in this situation.

Actual Behavior

Once I make the first selection. The starting point of that selection remains anchored there during repeated attempts to adjust what is highlighted. This occurs quite often when I miss the correct character position on screen that I need for the starting point often causing it to get truncated when I finally hit Copy. On the next Copy operation, I can select a new starting point, but I have to hit Copy each time I want to change the anchor point if it doesn't start where I want it it.

Originally created by @penguin359 on GitHub (Sep 22, 2021). ### Windows Terminal version (or Windows build number) 1.10.2383.0 ### Other Software vim 8.1 (inside WSL with mouse support) tmux 3.0a (inside WSL with mouse support) ### Steps to reproduce This issue can be produced with either Vim or Tmux. With vim, do the following: 1. Open any file in Vim. $ vim ~/.bashrc 2. Enable mouse support. :set ttymouse=xterm2 :set mouse=a 3. At this point, regular mouse events go to the app. However, if I want to use Windows Terminal to copy/paste something, I can hold down Shift when using the mouse. Highlight some word on the screen. 4. Try highlighting a different word/line instead. The same can be replicated in Tmux: 1. Open tmux $ tmux new 2. Enable mouse support Ctrl-b : set -g -q mouse on 3. Proceed the same as step 3 above. ### Expected Behavior I am expecting for Shift to allow me to send mouse events to Windows Terminal and have it act the same as if I was using the mouse normally, but without a mouse-aware terminal program. I am looking for a way have a mouse-aware terminal app running, but still have the option to use the Windows Terminal's mouse support for copy/pasting text as needed. I spend most of my time inside tmux using multiple panes and heavy use of it's mouse support to switch panes, but still need to access Windows Terminal for certain copy/paste operations. Other terminal apps that do the expected behavior include PuTTY on Windows with it's interaction with Shift allowing me to control PuTTY instead of sending the mouse event to tmux/vim and Gnome Terminal on Linux though it uses Control for the same purpose. I believe iTerm2 on macOS also implements this behavior, but with Alt. I have not found any modified key for Windows Terminal that allows me to use the mouse unencumbered in this situation. ### Actual Behavior Once I make the first selection. The starting point of that selection remains anchored there during repeated attempts to adjust what is highlighted. This occurs quite often when I miss the correct character position on screen that I need for the starting point often causing it to get truncated when I finally hit Copy. On the next Copy operation, I can select a new starting point, but I have to hit Copy each time I want to change the anchor point if it doesn't start where I want it it.
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 Needs-Author-Feedback Needs-Tag-Fix Needs-Triage No-Recent-Activity 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#15308
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?