The Bracketed Paste Mode can be enabled by writing \e[?2004h to STDOUT on a terminal that supports the mode. When pasting text with the Bracketed Paste Mode turned on, the terminal will wrap the copied text by the start sequences \e[200~ and the end sequences \e[201~.
Today, Console.ReadKey returns a set of VT sequences for the start/end of bracketed paste.
As is shown in the below screenshot, when pasting the letter C in WSL 2 with Windows Terminal (either by Ctrl+Shift-v or right-clicking), Console.ReadKey returns "\e200~C\e201~". It's essentially the expected start/end sequences for bracketed paste, but [ is missing from both.
Question 1: Is it a bug that [ is missed from the VT sequences returned by Console.ReadKey?
Question 2: Is the current behavior of Console.ReadKey regarding Bracketed Paste Mode supposed to be reliable or it just happens to work this way? Can an application depend on today's behavior to handle bracketed paste (e.g. powershell)?
Related PowerShell issue: PowerShell/PSReadLine#1471
The Bracketed Paste Mode can be enabled by writing
\e[?2004hto STDOUT on a terminal that supports the mode. When pasting text with the Bracketed Paste Mode turned on, the terminal will wrap the copied text by the start sequences\e[200~and the end sequences\e[201~.Today,
Console.ReadKeyreturns a set of VT sequences for the start/end of bracketed paste.As is shown in the below screenshot, when pasting the letter
Cin WSL 2 with Windows Terminal (either by Ctrl+Shift-v or right-clicking),Console.ReadKeyreturns"\e200~C\e201~". It's essentially the expected start/end sequences for bracketed paste, but[is missing from both.Question 1: Is it a bug that
[is missed from the VT sequences returned byConsole.ReadKey?Question 2: Is the current behavior of
Console.ReadKeyregarding Bracketed Paste Mode supposed to be reliable or it just happens to work this way? Can an application depend on today's behavior to handle bracketed paste (e.g. powershell)?Related PowerShell issue: PowerShell/PSReadLine#1471