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

[jypeter]

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 Feature Request - X like copy / paste #1332 Feature: add copy on select (per Unix terminals)  #524 and Feature Request: PuTTY style text selection #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

The WSLtty Selection and Mouse settings screenshots show similar settings

[WSLUser]

Note middle mouse input options such as paste are not yet available. See #1553.

[jypeter]

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

[WSLUser]

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.

[jypeter]

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

[WSLUser]

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.

[DHowett]

("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)

[WSLUser]

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

[jypeter]

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 Feature Request: Mouse/Touch/Pointer Bindings (like middle-click paste, right-click context menu, etc.) #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 Feature Request: Mouse/Touch/Pointer Bindings (like middle-click paste, right-click context menu, etc.) #1553. It mentions We definitely need a spec at the beginning, but xterm is only mentioned when citing my issue and the closed Settings option to make mouse operations behave like Xterm (middle button pastes) #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

[WSLUser]

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.

[jypeter]

Impressive! I'm completely out of my depth there

[DHowett]

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]

/dup #1553
I renamed the issue as well

[ghost]

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!