Support "Paste Bracketing"

Description of the new feature/enhancement

For some readline experiences, they support this concept of paste bracketing.

The idea is simple:

• First, the shell emits esc[?2004h
• This tells the terminal that this shell wants to use paste bracketing
• When paste bracketing is on, pasted text is prefixed by <kbd>esc</kbd>[200~ and followed by <kbd>esc</kbd>[201~ by the terminal before sending the text to the shell.

Here’s an example screenshot of my version of bash on macOS with readline (which doesn’t support this but you can see the effect):

• first command tells the terminal to deactivate bracketed pasting
• second is a paste from the clipboard
• 3rd activates bracketed pasting
• 4th is the same paste from the clipboard but now it has \e[200~ and \e[201~ around it

Pretty much any terminal supports this… for example, here’s iTerm2’s doc: https://gitlab.com/gnachman/iterm2/-/wikis/Paste-Bracketing#control-sequences

And there’s a feature request in Windows Terminal: https://github.com/microsoft/terminal/issues/395

and @Tyriar was considering adding this to VS Code’s terminal as well.

What does supporting this mean?

This means that on macOS and Linux (and really crossplat) we can support multi-line pasting - something that has been available on Windows in conhost.exe for a very long time.

Proposed technical implementation details (optional)

At start up, PSReadLine emits \e[?2004h to tell the terminal to use paste bracketing

When we get \e[200~ we can wait until \e[201~ before actually executing anything. (or we can wait for the ENTER after \e[201~)

[skyline75489]

With https://github.com/microsoft/terminal/pull/9034 merged, bracketed paste is supported in Windows Terminal. I’d love to see it in PSReadLine, too.

[daxian-dbw]

Feature requesting issue opened on .NET repo: https://github.com/dotnet/runtime/issues/60107 Also opened an issue to ask for clarification on the current behavior of Console.ReadKey regarding the start/end sequences of bracketed paste: https://github.com/dotnet/runtime/issues/60101

In summary, the dependencies for fixing this in PowerShell are:

1. [API Proposal]: Allow Console.ReadKey to parse VT sequences when ENABLE_VIRTUAL_TERMINAL_INPUT is set on Windows
2. Console.ReadKey returns incomplete VT sequences for bracketed paste
3. Support bracketed paste in conhost

---

Be noted that, today some key-bindings (e.g. <kbd>Ctrl+[</kbd>) work on Windows but not on Unix platforms because on Unix Console.ReadKey needs to parse/map VT sequences to ConsoleKeyInfo and thus those key-bindings are interpreted differently.

Assuming dotnet/runtime#60107 is addressed in .NET using the same parsing/mapping code that works on Unix, then those key-bindings will stop working on Windows once we switch to the new mode of Console.ReadKey in order to enable ENABLE_VIRTUAL_TERMINAL_INPUT on Windows. That would definitely be a breaking change. So, when working on this fix (after all dependencies are ready), we may need to consider to have this fix an opt-in feature, instead of the default.