starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Soft line breaks option when pasting from clipboard #20029

New Issue
Closed
opened 2026-01-31 07:01:14 +00:00 by claunia · 14 comments
claunia commented 2026-01-31 07:01:14 +00:00
Owner
Copy Link

Originally created by @o-sdn-o on GitHub (Jun 3, 2023).

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 https://github.com/PowerShell/PSReadLine/issues/579

Current behavior

https://github.com/microsoft/terminal/assets/11535558/29a74316-1e77-437a-ac52-7f2f094242b8

Behavior with Shift modifier added to Return key event

https://github.com/microsoft/terminal/assets/11535558/9313c3c8-87c2-430a-9b69-6538a0f47b07

Originally created by @o-sdn-o on GitHub (Jun 3, 2023). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 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 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. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # 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. <!-- A clear and concise description of what you want to happen. --> 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 https://github.com/PowerShell/PSReadLine/issues/579 Current behavior https://github.com/microsoft/terminal/assets/11535558/29a74316-1e77-437a-ac52-7f2f094242b8 Behavior with Shift modifier added to Return key event https://github.com/microsoft/terminal/assets/11535558/9313c3c8-87c2-430a-9b69-6538a0f47b07
claunia commented 2026-01-31 07:01:16 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Jun 7, 2023):

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
@carlos-zamora commented on GitHub (Jun 7, 2023): 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
claunia commented 2026-01-31 07:01:16 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 7, 2023):

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. 😄

@DHowett commented on GitHub (Jun 7, 2023): 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. :smile:
claunia commented 2026-01-31 07:01:17 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jun 8, 2023):

For reference, the PSReadLine bracketed paste issue is here: https://github.com/PowerShell/PSReadLine/issues/1471

@j4james commented on GitHub (Jun 8, 2023): For reference, the PSReadLine bracketed paste issue is here: https://github.com/PowerShell/PSReadLine/issues/1471
claunia commented 2026-01-31 07:01:17 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 8, 2023):

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 commented on GitHub (Jun 8, 2023): > 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.
claunia commented 2026-01-31 07:01:17 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 8, 2023):

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 commented on GitHub (Jun 8, 2023): The reason why this will never happen is that `ReadConsoleInput` is an almost perfect (almost bcz it is [codepoint based](https://en.wikipedia.org/wiki/Code_point) only) keyboard protocol. This is literally a keyboard protocol, not a binary stream reading function. Until an alternative and completely perfect ([grapheme cluster based](https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries)) 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.
claunia commented 2026-01-31 07:01:18 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 8, 2023):

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.

@o-sdn-o commented on GitHub (Jun 8, 2023): 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.
claunia commented 2026-01-31 07:01:18 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jun 8, 2023):

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?

@j4james commented on GitHub (Jun 8, 2023): 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?
claunia commented 2026-01-31 07:01:18 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 8, 2023):

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 commented on GitHub (Jun 8, 2023): > 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.
claunia commented 2026-01-31 07:01:19 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 8, 2023):

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)

https://github.com/microsoft/terminal/assets/11535558/d65cd3d8-39ca-4fc8-9ca7-45c85992dbcf

The same result with enabled bracketed paste:

https://github.com/microsoft/terminal/assets/11535558/7770de67-03fd-40ce-80dc-e3513d6ef242

@o-sdn-o commented on GitHub (Jun 8, 2023): 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) https://github.com/microsoft/terminal/assets/11535558/d65cd3d8-39ca-4fc8-9ca7-45c85992dbcf The same result with enabled bracketed paste: https://github.com/microsoft/terminal/assets/11535558/7770de67-03fd-40ce-80dc-e3513d6ef242
claunia commented 2026-01-31 07:01:19 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 8, 2023):

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.

@DHowett commented on GitHub (Jun 8, 2023): > 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 <kbd>Shift+Enter</kbd> instead of <kbd>Enter</kbd> for newlines only works for Terminal and PowerShell _and then_ only so long as nobody is in between the two.
claunia commented 2026-01-31 07:01:19 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 9, 2023):

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 commented on GitHub (Jun 9, 2023): > 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.
claunia commented 2026-01-31 07:01:19 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 9, 2023):

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 commented on GitHub (Jun 9, 2023): WT already owns the almost general keyboard protocol - [Win32 Input Mode](https://github.com/microsoft/terminal/blob/main/doc/specs/%234999%20-%20Improved%20keyboard%20handling%20in%20Conpty.md). 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.
claunia commented 2026-01-31 07:01:20 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 10, 2023):

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

@o-sdn-o commented on GitHub (Jun 10, 2023): Ок. It is just another nice #8343 try to rise the cli interactivity level up.
claunia commented 2026-01-31 07:01:20 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Jun 10, 2023):

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

image

@o-sdn-o commented on GitHub (Jun 10, 2023): My idea disproof: Far Manager Editor treats `Shift+Enter` as its own macro, not as a soft line break ![image](https://github.com/microsoft/terminal/assets/11535558/7b743e6d-0bea-43c0-8ef1-78ce7db901b3)
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 Area-Interaction Help Wanted Issue-Feature Needs-Tag-Fix 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#20029
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?