starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 08:24:54 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Feature request: add xterm-style select/copy/paste options #10649

New Issue
Closed
opened 2026-01-31 02:26:34 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 02:26:34 +00:00
Owner
Copy Link

Originally created by @jypeter on GitHub (Sep 16, 2020).

Description of the new feature/enhancement

WSL + Ubuntu (+ an X server) is a light and awesome replacement to running Ubuntu inside a virtual machine (e.g. VirtualBox). Linux users also need a terminal that will mimic what they have been using for years (25 years in my case) in the way of selecting, copying and pasting text

I'm currently using PuTTY and WSLtty to achieve this goal and I thought I would give the Windows terminal a try, because it looks quite promising. Unfortunately:

  • there is no GUI yet for easily changing the options/settings. I understand this is a work in progress and I could edit the required json file
  • there does not seem to be a way (yet) to mimic all the usual (and I'd say de facto standard for some people, after so many years) xterm select/copy/paste behavior. I have checked the documentation and read the #1332 #524 and #1496 issues that seemed to address this problem, and were possibly closed a bit hastily

The PuTTY Selection settings screenshot below shows the xterm setting I'm using. It would be useful for a lot of people if there was a way to easily activate xterm-style behavior in the Windows terminal. Maybe this is already possible, but I have checked several sections of the Terminal documentation (tips and tricks, tutorials, Customize settings, ...) without any success

Putty_05

The WSLtty Selection and Mouse settings screenshots show similar settings
WSLtty_01
WSLtty_02

Originally created by @jypeter on GitHub (Sep 16, 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 WSL + Ubuntu (+ an X server) is a light and awesome replacement to running Ubuntu inside a virtual machine (e.g. VirtualBox). **Linux users also need a terminal that will mimic what they have been using for years** (25 years in my case) **in the way of selecting, copying and pasting text** I'm currently using [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) and [WSLtty ](https://github.com/mintty/wsltty)to achieve this goal and I thought I would give the **Windows terminal** a try, because it looks quite promising. Unfortunately: - there is no GUI yet for easily changing the options/settings. I understand this is a work in progress and I could edit the required _json_ file - there does not seem to be a way (yet) to mimic all the usual (and I'd say _de facto_ standard for some people, after so many years) **_xterm_ select/copy/paste behavior**. I have checked the documentation and read the #1332 #524 and #1496 issues that seemed to address this problem, and were possibly closed a bit hastily The PuTTY _Selection_ settings screenshot below shows the _xterm_ setting I'm using. It would be useful for a lot of people if there was a way to easily activate xterm-style behavior in the Windows terminal. Maybe this is already possible, but I have checked several sections of the [Terminal documentation](https://docs.microsoft.com/en-us/windows/terminal/) (_tips and tricks_, _tutorials_, _Customize settings_, ...) without any success ![Putty_05](https://user-images.githubusercontent.com/2785573/93341808-d55c4700-f82e-11ea-8849-ad2303099d8f.png) The WSLtty _Selection_ and _Mouse_ settings screenshots show similar settings ![WSLtty_01](https://user-images.githubusercontent.com/2785573/93346199-fffcce80-f833-11ea-8bb8-845cec9033a9.png) ![WSLtty_02](https://user-images.githubusercontent.com/2785573/93346215-05f2af80-f834-11ea-8cf3-7e6bee446e5f.png)
claunia added the Issue-FeatureResolution-Duplicate labels 2026-01-31 02:26:35 +00:00
claunia commented 2026-01-31 02:26:35 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Sep 16, 2020):

Note middle mouse input options such as paste are not yet available. See https://github.com/microsoft/terminal/issues/1553.

@WSLUser commented on GitHub (Sep 16, 2020): Note middle mouse input options such as paste are not yet available. See https://github.com/microsoft/terminal/issues/1553.
claunia commented 2026-01-31 02:26:35 +00:00
Author
Owner
Copy Link

@jypeter commented on GitHub (Sep 16, 2020):

I have changed the default settings.json to look like this

[...]
    // If enabled, selections are automatically copied to your clipboard.
    "copyOnSelect": false,
    "experimental.input.forceVT": true,

    // If enabled, formatted data is also copied to your clipboard
    "copyFormatting": false,
[...]

and exited then opened a new Terminal, but the behavior seems very much like the default behavior

  • select text with left mouse button: copy
  • middle button: does nothing (should paste)
  • DOUBLE-click with right mouse button: paste
  • subsequent SINGLE-clicks with right mouse button: paste again (should extend or show context menu)

Oh, I just saw your extra note about No middle button support !

Is "experimental.input.forceVT": true just the same as "copyOnSelect": false for now? Or am I missing some subtle things?

I'm using Terminal version 1.2.2381.0 straight out of the Store, not the Preview

@jypeter commented on GitHub (Sep 16, 2020): I have changed the default settings.json to look like this ``` [...] // If enabled, selections are automatically copied to your clipboard. "copyOnSelect": false, "experimental.input.forceVT": true, // If enabled, formatted data is also copied to your clipboard "copyFormatting": false, [...] ``` and exited then opened a new Terminal, but the behavior seems very much like the default behavior - select text with left mouse button: copy - **middle button: does nothing** (should paste) - DOUBLE-click with right mouse button: paste - subsequent SINGLE-clicks with right mouse button: paste again (should extend or show context menu) Oh, I just saw your extra note about _No middle button support_ ! Is` "experimental.input.forceVT": true` just the same as `"copyOnSelect": false` for now? Or am I missing some subtle things? I'm using Terminal version `1.2.2381.0` straight out of the Store, not the _Preview_
claunia commented 2026-01-31 02:26:36 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Sep 16, 2020):

Yeah it isn't related in this case. When win32 input mode was added, the option helped alleviate some issues as a workaround. Just subscribe and upvote the issue above. It's known but not the priority (at least not until enough people upvote and ask on Twitter to bump priority of that issue.) Of course anyone is welcome to submit a PR resolving the issue.

@WSLUser commented on GitHub (Sep 16, 2020): Yeah it isn't related in this case. When win32 input mode was added, the option helped alleviate some issues as a workaround. Just subscribe and upvote the issue above. It's known but not the priority (at least not until enough people upvote and ask on Twitter to bump priority of that issue.) Of course anyone is welcome to submit a PR resolving the issue.
claunia commented 2026-01-31 02:26:36 +00:00
Author
Owner
Copy Link

@jypeter commented on GitHub (Sep 16, 2020):

Done (I think). I clicked on the "thumb-up"

Can my issue remain open till this is resolved and documented, if other users have the same request?

I had a hard time finding older (and unfortunately closed) issues describing what I need. It seems that we (Linux users) are not using exactly the same keywords or feature description as the Terminal developers

@jypeter commented on GitHub (Sep 16, 2020): Done (I think). I clicked on the "thumb-up" Can my issue remain open till this is resolved and documented, if other users have the same request? I had a hard time finding older (and unfortunately closed) issues describing what I need. It seems that we (Linux users) are not using exactly the same keywords or feature description as the Terminal developers
claunia commented 2026-01-31 02:26:36 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Sep 16, 2020):

just search xterm-style or middle mouse. You'll find plenty closed issues. This is a dupe of the issue above and it's tracked there so this issue will be closed by a WT team member.

@WSLUser commented on GitHub (Sep 16, 2020): just search xterm-style or middle mouse. You'll find plenty closed issues. This is a dupe of the issue above and it's tracked there so this issue will be closed by a WT team member.
claunia commented 2026-01-31 02:26:36 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 16, 2020):

("experimental.input.forceVT": true should only be used if you're having keyboard input issues that impact text-mode applications; if you are, we'd like to know what they are because otherwise we'll never be able to address them. @WSLUser: don't recommend it unless people are experiencing keyboard input issues that impact text-mode applications)

@DHowett commented on GitHub (Sep 16, 2020): (`"experimental.input.forceVT": true` should only be used if you're having _keyboard input issues that impact text-mode applications_; if you **are**, we'd like to know what they are because otherwise we'll never be able to address them. @WSLUser: don't recommend it unless people are experiencing _keyboard input issues that impact text-mode applications_)
claunia commented 2026-01-31 02:26:36 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Sep 16, 2020):

I removed that recommendation quickly once I realized it was different issue but unfortunately it was followed before I removed it.

@WSLUser commented on GitHub (Sep 16, 2020): I removed that recommendation quickly once I realized it was different issue but unfortunately it was followed before I removed it.
claunia commented 2026-01-31 02:26:37 +00:00
Author
Owner
Copy Link

@jypeter commented on GitHub (Sep 17, 2020):

Well, well, I still believe that this issue or a similar one should stay open till the Feature request in the title is resolved, unless of course somebody argues convincingly that the feature is unreasonable or undoable

  • I have searched the issues with is:issue xterm in:title and is:issue middle in:title, and even is:open paste in:title (and putty, wsltty, mintty) and all the relevant issues are closed! I may be wrong, but when there is an issue or a feature request and you don't find it in the open issues, it means that either nobody as reported it (and it is your duty to do it), or it has been solved (possibly in a more recent or beta version). You should not have to look for a closed issue in this particular case (I did, but it took me some time)
  • this is indeed very similar to Feature Request: Mouse/Touch/Pointer Bindings #1553 that you mentioned, but unfortunately the wording of the title is quite different! I'd say that my issue is a functionality request from the users' point of view, whereas the other issue if an implementation request from the developers' point of view, that can be used to fulfill my request
  • I've had a look at #1553. It mentions We definitely need a spec at the beginning, but xterm is only mentioned when citing my issue and the closed #7624. Well, there you have part of the spec : make it possible to reproduce xterm behavior! Besides the screenshots I have included above show all the different settings that similar terminal programs have, and which settings are used to reproduce xterm behavior :-) That's something that can probably go to the specs
@jypeter commented on GitHub (Sep 17, 2020): Well, well, I still believe that this issue or a similar one should stay open till the _Feature request_ in the title is resolved, unless of course somebody argues convincingly that the feature is unreasonable or undoable - I have searched the issues with `is:issue xterm in:title` and `is:issue middle in:title`, and even `is:open paste in:title` (and _putty_, _wsltty_, _mintty_) and **all the relevant issues are closed**! I may be wrong, but when there is an issue or a feature request and you don't find it in the open issues, it means that either nobody as reported it (and it is your duty to do it), or it has been solved (possibly in a more recent or beta version). You should not have to look for a closed issue in this particular case (I did, but it took me some time) - this is indeed very similar to _Feature Request: Mouse/Touch/Pointer Bindings_ #1553 that you mentioned, but unfortunately the wording of the title is quite different! I'd say that my issue is a functionality request from the **users' point of view**, whereas the other issue if an implementation request from the **developers' point of view**, that can be used to fulfill my request - I've had a look at #1553. It mentions _We definitely need a spec_ at the beginning, but xterm is only mentioned when citing my issue and the closed #7624. Well, there you have part of the spec : _make it possible to reproduce xterm behavior_! Besides the screenshots I have included above show all the different settings that similar terminal programs have, and which settings are used to reproduce xterm behavior :-) That's something that can probably go to the specs
claunia commented 2026-01-31 02:26:37 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Sep 17, 2020):

The spec is needed to actually implement the behavior. Take a look at https://github.com/microsoft/terminal/tree/master/doc/specs. You'll start to see why, especially with some of the bigger features, why a spec is needed for this feature.

@WSLUser commented on GitHub (Sep 17, 2020): The spec is needed to actually implement the behavior. Take a look at https://github.com/microsoft/terminal/tree/master/doc/specs. You'll start to see why, especially with some of the bigger features, why a spec is needed for this feature.
claunia commented 2026-01-31 02:26:37 +00:00
Author
Owner
Copy Link

@jypeter commented on GitHub (Sep 17, 2020):

Impressive! I'm completely out of my depth there

@jypeter commented on GitHub (Sep 17, 2020): Impressive! I'm completely out of my depth there
claunia commented 2026-01-31 02:26:38 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 22, 2020):

Thanks for all the feedback. Here--I'll merge a bit of this discussion into the body of #1553 so that it comes up when you search for it. I appreciate that some of our workitems are developer-focused, but that's unfortunately the best way to make sure the dev team understands the scope of the problem 😄

@DHowett commented on GitHub (Sep 22, 2020): Thanks for all the feedback. Here--I'll merge a bit of this discussion into the body of #1553 so that it comes up when you search for it. I appreciate that some of our workitems are developer-focused, but that's unfortunately the best way to make sure the dev team understands the scope of the problem :smile:
claunia commented 2026-01-31 02:26:38 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 22, 2020):

/dup #1553
I renamed the issue as well

@DHowett commented on GitHub (Sep 22, 2020): /dup #1553 I renamed the issue as well
claunia commented 2026-01-31 02:26:38 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 22, 2020):

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 (Sep 22, 2020): 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 Issue-Feature 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#10649
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?