-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Console.ReadKey
returns incomplete VT sequences for bracketed paste
#60101
Comments
Tagging subscribers to this area: @dotnet/area-system-console Issue DetailsThe Bracketed Paste Mode can be enabled by writing Today, Question 1: Is it a bug that
|
/cc @lzybkr, @SteveL-MSFT and @DHowett-MSFT FYI |
@adamsitnik Another scenario worth re-testing with #802 |
Fixed by #72193 |
Quote from #73257 (comment):
|
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 byConsole.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 text was updated successfully, but these errors were encountered: