Soft line breaks option when pasting from clipboard

[o-sdn-o]

Description of the new feature/enhancement

Consider adding a soft line break option for pasting from the clipboard when ENABLE_PROCESSED_INPUT is disabled (e.g. pwsh -Interactive). This will allow users to paste multi-line text from the clipboard into a powershell-like shell as a single blob without line-by-line execution.

Proposed technical implementation details (optional)

In my opinion, this is enough to add a Shift modifier to the generated Return key when converting a text string into keypress events.

When the Shift key is pressed in shells like powershell, a soft line break is added instead of executing the current line.

Related to #3449
x-link PowerShell/PSReadLine#579

Current behavior

Terminal.Dev.2023-06-03.23-49-31.mp4

Behavior with Shift modifier added to Return key event

Terminal.Dev.2023-06-03.23-48-34.mp4

[carlos-zamora]

The proper implementation of this feature (imo) would include:

• a setting on the "paste" action
• a setting on right clicking
• updating the multi-line paste warning

[DHowett]

FWIW, I think it is strictly better for PowerShell to implement support for bracketed paste, which will also give it support for soft paste in other terminal emulators.

I am somewhat worried about us committing to a niche feature when the right one is on the table. 😄

[j4james]

For reference, the PSReadLine bracketed paste issue is here: PowerShell/PSReadLine#1471

[o-sdn-o]

I think it is strictly better for PowerShell to implement support for bracketed paste

It is never happens because it would definitely be a breaking change for them.

This will only be done when powershell/PSReadLine/.Net completely moves from the practice of using ReadConsoleInputW to ReadFile to read input. That is, it will never happen.

WT supports this practice from the very beginning. WT is responsible for converting raw text strings into pressed keys. I think it makes sense to keep this practice until the end, as long as it is used by dependent projects.

[o-sdn-o]

The reason why this will never happen is that ReadConsoleInput is an almost perfect (almost bcz it is codepoint based only) keyboard protocol. This is literally a keyboard protocol, not a binary stream reading function. Until an alternative and completely perfect (grapheme cluster based) keyboard protocol is provided, no one will stop using ReadConsoleInput. So it's more likely that the Unix world will come up with an analogue of ReadConsoleInput than switch to using raw ReadFile.

PS: I apologize for using you instead of WT in my past and future posts, because in Slavic languages you may not be considered impolite as it is in English.

[o-sdn-o]

I have nothing against bracketed paste, but here it's just about setting only one bit (Shift modifier) for only one keyboard event associated with the Return key in the stream of generated keyboard events. It is not supposed to change or substitute characters or anything like that here. Setting only one flag, which is only looked at by those who are waiting for soft breaks. What will it affect? Or what could it break? Powershell maintainers invent a heuristic for detecting the paste action from the clipboard by measuring the time between keyboard events, and here WT only needs to insert one bit in one place and the long-standing question is closed.

[j4james]

How would this work on other platforms, though, since PowerShell also runs on Linux and macOS? Like if you've got two panes open in Windows Terminal, one side with Windows PowerShell and the other a Linux version of PowerShell under WSL, would soft line breaks only be expected to work in one pane?

[o-sdn-o]

How would this work on other platforms, though, since PowerShell also runs on Linux and macOS? Like if you've got two panes open in Windows Terminal, one side with Windows PowerShell and the other a Linux version of PowerShell under WSL, would soft line breaks only be expected to work in one pane?

My guess is that the Shift modifier of the Enter key event will be ignored when translating the event stream to a text string. Something like INPUT_RECORD{ Shift+Enter } => \r or \n. Perhaps this solution will be only for Windows.

[o-sdn-o]

In my setup the behavior of pwsh in WSL does not depend on the presence of the Shift modifier

• Left pane: pwsh on Windows
• Right pane: pwsh on WSL+Ubuntu 22.04

Test with powershell amd64 7.3.4-1.deb on WSL Ubuntu 22.04 (Bracketed paste is Disabled, Shift modifier is applied to the Return key event)

Terminal.Dev.2023-06-08.23-17-40.mp4

The same result with enabled bracketed paste:

Terminal.Dev.2023-06-09.00-35-40.mp4

[DHowett]

Perhaps this solution will be only for Windows.

See, this is the thing I have an issue with! Yeah, INPUT_EVENT records are great, but they just don't remote well and they are not cross-platform. I don't think that means we shouldn't use them!

I just think: there is a standard for terminals to emit unmodified pasted text that works across the entire ecosystem, over ssh, on other platforms, etc.; why should we be the odd ones out and do something that only works properly when you're running a shell directly on Windows with no intermediary?

PowerShell adding support for bracketed paste (yes, it will require them to do some work.) fixes PowerShell on macOS with iTerm2, Linux with foot and Konsole and libvte-based terminals, FreeBSD, etc. anywhere it runs.

Windows Terminal adding support for pasted content being emitted with Shift+Enter instead of Enter for newlines only works for Terminal and PowerShell and then only so long as nobody is in between the two.

[o-sdn-o]

PowerShell on macOS with iTerm2, Linux with foot and Konsole and libvte-based terminals, FreeBSD, etc. anywhere it runs

Thirst of all they need a keyboard protocol to provide Shift+Enter multiline user experience. The bracketed paste support is just a small addon.

why should we be the odd ones out and do something that only works properly when you're running a shell directly on Windows

I think because others lack of keyboard protocol and they must invent it.

INPUT_EVENT records are great, but they just don't remote well and they are not cross-platform

The General Keyboard Protocol will allow everyone to seamlessly migrate to it from using INPUT_RECORDS in the future.

[o-sdn-o]

WT already owns the almost general keyboard protocol - Win32 Input Mode. Just extend it to allow an arbitrary number of code points contained at the end of the vt-sequence to be grapheme cluster aware. And allow the stream of these sequences to be interleaved with the raw text stream. An application that expects WIN32_INPUT_MODE will simply ignore the raw text stream.

[o-sdn-o]

Ок. It is just another nice #8343 try to rise the cli interactivity level up.

[o-sdn-o]

My idea disproof: Far Manager Editor treats Shift+Enter as its own macro, not as a soft line break