Skip to content
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

Closed
Tracked by #64487
daxian-dbw opened this issue Oct 6, 2021 · 5 comments · Fixed by #72193
Closed
Tracked by #64487

Console.ReadKey returns incomplete VT sequences for bracketed paste #60101

daxian-dbw opened this issue Oct 6, 2021 · 5 comments · Fixed by #72193
Assignees
Milestone

Comments

@daxian-dbw
Copy link
Contributor

daxian-dbw commented Oct 6, 2021

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

image

@dotnet-issue-labeler dotnet-issue-labeler bot added area-System.Console untriaged New issue has not been triaged by the area owner labels Oct 6, 2021
@ghost
Copy link

ghost commented Oct 6, 2021

Tagging subscribers to this area: @dotnet/area-system-console
See info in area-owners.md if you want to be subscribed.

Issue Details

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)?

image

Author: daxian-dbw
Assignees: -
Labels:

area-System.Console, untriaged

Milestone: -

@daxian-dbw
Copy link
Contributor Author

daxian-dbw commented Oct 7, 2021

/cc @lzybkr, @SteveL-MSFT and @DHowett-MSFT FYI

@jeffhandley jeffhandley added needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration and removed untriaged New issue has not been triaged by the area owner labels Oct 9, 2021
@jeffhandley jeffhandley added this to the 7.0.0 milestone Oct 9, 2021
@jeffhandley
Copy link
Member

@adamsitnik Another scenario worth re-testing with #802

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Aug 2, 2022
@adamsitnik adamsitnik self-assigned this Aug 2, 2022
@adamsitnik adamsitnik removed the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Aug 2, 2022
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Aug 10, 2022
@adamsitnik
Copy link
Member

Fixed by #72193

@daxian-dbw
Copy link
Contributor Author

Quote from #73257 (comment):

We want the tags to be preserved by ReadKey instead of being stripped off.

Thanks for the confirmation! In such a case this issue has been fixed with #73257 and the missing [ chars should be back now.

@ghost ghost locked as resolved and limited conversation to collaborators Sep 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants