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

Bracketed Paste appears either non-functional, or disabled #12848

New Issue
Closed
opened 2026-01-31 03:26:33 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 03:26:33 +00:00
Owner
Copy Link

Originally created by @jnikolich on GitHub (Mar 3, 2021).

Environment

Local OS:  Windows 10 Home 20H2 build 19042.804
Windows Terminal:  v1.7.502.0

Any other software?
OpenSSH:  OpenSSH_for_Windows_7.7p1
Remote OS:  Fedora 33 (64-bit)
Remote Editor:  vim 8.2

Steps to reproduce

  1. Open up two windows-terminal sessions (wt version 1.7.502.0) to a remote host. (wt version can be verified with wt --version from a cmd prompt.)
  2. Open up vim in each session.
  3. Verify that Vim is at version 8.x or higher by entering the the following Vim command: :version (pressing enter afterward).
  4. Verify that Vim's native bracketed-paste support is active with the following command : :set t_BE? t_BD? t_PS? t_PE? (pressing enter afterward).
  5. Copy a block of (indented) code from one session, and paste into the other (I tested with both mouse r-click and shift-ctrl-v).
  6. Repeat the preceding steps but using PuTTY instead of windows-terminal for the session you will be pasting into.

Expected behavior

Vim (which supports bracketed-paste natively) should be getting triggered into entering auto-enter "paste" mode when pasting the block of text, resulting in things like correct indentation.

Actual behavior

Vim, when running in a windows-terminal session, does not appear to be getting triggered to enter "paste" mode during the paste operation.
If similar tests are performed pasting into Vim within a PuTTY session (with all other things being equal), the test succeeds.

Further information

If I understand things correctly (and that's never a given), then Vim has natively supported bracketed-paste mode since version 8.x. If Vim detects a bracketed-paste capable terminal emulator (I believe it does this based on the contents of the $TERM shell environment variable being some derivative of xterm, then it sets several options accordingly. These options are:

t_BE = "\e[?2004h"      // Sent to the terminal when entering raw mode
t_BD = "\e[?2004l"      // Sent to the terminal when exiting raw mode
t_PS =\e[200~"          // Terminal should prepend this to pasted text
t_PE =\e[201~"          // Terminal should append this to pasted text

If Vim's option t_BE is not set, then this behaviour is not performed.

After installing windows-terminal 1.7.502.0, I then opened up two SSH sessions to the same remote host, fired up Vim within both sessions, and tried copy/pasting some indented code. Bracketed paste appeared not to work / be detected, as the pasted code had its indenting messed up. When Vim's "paste" mode was manually activated and the tests repeated, the pasted code now appeared properly indented.

I then repeated these tests pasting from windows-terminal to Vim within a PuTTY session on the same remote host, and bracketed-paste worked right away. I also pasted from PuTTY to windows-terminal, without success. Lastly I tested PuTTY to PuTTY, which worked as expected.

In the case of windows-terminal to windows-terminal, I tested both between 2 panes within the same window, and between two separate windows-terminal windows.

In each test, I first verified that the Vim options mentioned above were properly set, and they were. I also verified that the shell's $TERM environment variable was set to something Vim would recognize as being bracketed-paste capable, and in my case it was correctly set to xterm-256color.

I researched the 8 git commits included in PR #9034 in-case there was a new settings option that needed to be added/enabled for bracketed-paste to work, but it didn't appear there is any.

This is all observational evidence - I don't have any debug logs or other diagnostic data that something is failing or is disabled. In particular, I'm wondering how to detect if I'm suffering from a version-conflict, e.g. with conpty.

If you can provide any guidance on further testing steps or ways to obtain concrete diagnostics, that would be greatly appreciated. If I am misunderstanding how windows-terminal or bracketed-paste operate, then my apologies and appreciation for any correction you might offer.

Originally created by @jnikolich on GitHub (Mar 3, 2021). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 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! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Local OS: Windows 10 Home 20H2 build 19042.804 Windows Terminal: v1.7.502.0 Any other software? OpenSSH: OpenSSH_for_Windows_7.7p1 Remote OS: Fedora 33 (64-bit) Remote Editor: vim 8.2 ``` # Steps to reproduce 1. Open up two windows-terminal sessions (wt version 1.7.502.0) to a remote host. (wt version can be verified with `wt --version` from a cmd prompt.) 1. Open up vim in each session. 1. Verify that Vim is at version **8.x or higher** by entering the the following Vim command: `:version` (pressing `enter` afterward). 1. Verify that Vim's native bracketed-paste support is active with the following command : `:set t_BE? t_BD? t_PS? t_PE?` (pressing `enter` afterward). 1. Copy a block of (indented) code from one session, and paste into the other (I tested with both mouse r-click and shift-ctrl-v). 1. Repeat the preceding steps but using PuTTY instead of windows-terminal for the session you will be pasting into. <!-- A description of how to trigger this bug. --> # Expected behavior Vim (which supports bracketed-paste natively) should be getting triggered into entering auto-enter "paste" mode when pasting the block of text, resulting in things like correct indentation. <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> # Actual behavior Vim, when running in a windows-terminal session, does not appear to be getting triggered to enter "paste" mode during the paste operation. If similar tests are performed pasting into Vim within a PuTTY session (with all other things being equal), the test succeeds. # Further information If I understand things correctly (and that's never a given), then Vim has natively supported bracketed-paste mode since version 8.x. If Vim detects a bracketed-paste capable terminal emulator (I believe it does this based on the contents of the $TERM shell environment variable being some derivative of *xterm*, then it sets several options accordingly. These options are: ``` t_BE = "\e[?2004h" // Sent to the terminal when entering raw mode t_BD = "\e[?2004l" // Sent to the terminal when exiting raw mode t_PS =\e[200~" // Terminal should prepend this to pasted text t_PE =\e[201~" // Terminal should append this to pasted text ``` If Vim's option `t_BE` is not set, then this behaviour is not performed. After installing windows-terminal 1.7.502.0, I then opened up two SSH sessions to the same remote host, fired up Vim within both sessions, and tried copy/pasting some indented code. Bracketed paste appeared not to work / be detected, as the pasted code had its indenting messed up. When Vim's "paste" mode was manually activated and the tests repeated, the pasted code now appeared properly indented. I then repeated these tests pasting *from* windows-terminal *to* Vim within a PuTTY session on the same remote host, and bracketed-paste worked right away. I also pasted *from* PuTTY *to* windows-terminal, without success. Lastly I tested PuTTY to PuTTY, which worked as expected. In the case of windows-terminal *to* windows-terminal, I tested both between 2 panes within the same window, and between two separate windows-terminal windows. In each test, I first verified that the Vim options mentioned above were properly set, and they were. I also verified that the shell's $TERM environment variable was set to something Vim would recognize as being bracketed-paste capable, and in my case it was correctly set to `xterm-256color`. I researched the 8 git commits included in PR #9034 in-case there was a new settings option that needed to be added/enabled for bracketed-paste to work, but it didn't appear there is any. This is all observational evidence - I don't have any debug logs or other diagnostic data that something is failing or is disabled. In particular, I'm wondering how to detect if I'm suffering from a version-conflict, *e.g.* with conpty. If you can provide any guidance on further testing steps or ways to obtain concrete diagnostics, that would be greatly appreciated. If I am misunderstanding how windows-terminal or bracketed-paste operate, then my apologies and appreciation for any correction you might offer. <!-- What's actually happening? -->
claunia added the Needs-TriageResolution-ExternalNeeds-Tag-Fix labels 2026-01-31 03:26:33 +00:00
claunia commented 2026-01-31 03:26:34 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 3, 2021):

Hey @jnikolich! Thanks for the detailed report, and sorry for the issue. This all boils down to one pernicious issue in OpenSSH for Windows. As of version 7.7, they do not support VT input. When the first did their port, they were manually reading Win32 console input events (they're structs that come out of the console host describing keyboard, mouse, etc.) and translating them into control sequences directly.

Unfortunately, this means that 7.7 doesn't know what to do when we send it the bracketed paste introducer/finalizer sequences¹. They're ignored², instead of passed through to the application.

We convinced them recently to let us (the Windows Console host) do the VT conversion, and they will faithfully pass it through unmodified. That's shipping in Win32-OpenSSH 8.1+.

¹ It actually never receives them. The console host that is doing "translation" for Terminal to speak to Win32 applications drops it, because OpenSSH hasn't said "please give me VT encoded input." For more info, look at the Win32-side docs for ENABLE_VIRTUAL_TERMINAL_INPUT.

² This is true of VT mouse input as well. ☹️

@DHowett commented on GitHub (Mar 3, 2021): Hey @jnikolich! Thanks for the detailed report, and sorry for the issue. This all boils down to one pernicious issue in OpenSSH for Windows. As of version 7.7, they _do not support VT input_. When the first did their port, they were manually reading Win32 console input events (they're structs that come out of the console host describing keyboard, mouse, etc.) and translating them into control sequences directly. Unfortunately, this means that 7.7 doesn't know what to do when we send it the bracketed paste introducer/finalizer sequences¹. They're ignored², instead of passed through to the application. We convinced them recently to let us (the Windows Console host) do the VT conversion, and they will faithfully pass it through unmodified. That's shipping in Win32-OpenSSH 8.1+. ¹ It actually never receives them. The console host that is doing "translation" for Terminal to speak to Win32 applications drops it, because OpenSSH hasn't said "please give me VT encoded input." For more info, look at the Win32-side docs for `ENABLE_VIRTUAL_TERMINAL_INPUT`. ² This is true of VT mouse input as well. ☹️
claunia commented 2026-01-31 03:26:34 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 3, 2021):

This should be fixed in OpenSSH 8.1+, so I'm gonna close this as external. We can reopen this if it turns out it's not.

@zadjii-msft commented on GitHub (Mar 3, 2021): This should be fixed in OpenSSH 8.1+, so I'm gonna close this as external. We can reopen this if it turns out it's not.
claunia commented 2026-01-31 03:26:35 +00:00
Author
Owner
Copy Link

@jnikolich commented on GitHub (Mar 3, 2021):

@DHowett: TYVM for the quick response and spot-on advice. I didn't figure that OpenSSH would be the culprit, and although I now see that their change-log hints at something impacting this, it never would have occurred to me to look in that direction. I'm sure glad I thought to post my OpenSSH version in the Environment section.

Confirmed: I repeated my tests while using OpenSSH for Windows 8.1p1, and bracketed-paste now works as expected.

Your support is very-much appreciated!

@jnikolich commented on GitHub (Mar 3, 2021): @DHowett: TYVM for the quick response and spot-on advice. I didn't figure that OpenSSH would be the culprit, and although I now see that their change-log hints at something impacting this, it never would have occurred to me to look in that direction. I'm sure glad I thought to post my OpenSSH version in the Environment section. Confirmed: I repeated my tests while using OpenSSH for Windows 8.1p1, and bracketed-paste now **works as expected**. Your support is very-much appreciated!
claunia commented 2026-01-31 03:26:35 +00:00
Author
Owner
Copy Link

@alparo commented on GitHub (Apr 10, 2021):

This issue still exist on WSL version of Ubuntu in the latest Windows Terminal Version.

@alparo commented on GitHub (Apr 10, 2021): This issue still exist on WSL version of Ubuntu in the latest Windows Terminal Version.
claunia commented 2026-01-31 03:26:35 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 10, 2021):

The latest preview version, or the latest stable version?

@DHowett commented on GitHub (Apr 10, 2021): The latest preview version, or the latest stable version?
claunia commented 2026-01-31 03:26:35 +00:00
Author
Owner
Copy Link

@alparo commented on GitHub (Apr 10, 2021):

The latest preview version, or the latest stable version?

Sorry. Should have mentioned the version.

Mine is 1.6.10571.0

And sorry again: the problem exist only in NeoVim (nvim). In the classical Vim paste works as expected without problems. Seems, that I should address the issue to nvim developers.

@alparo commented on GitHub (Apr 10, 2021): > > > The latest preview version, or the latest stable version? Sorry. Should have mentioned the version. Mine is 1.6.10571.0 And sorry again: the problem exist only in NeoVim (nvim). In the classical Vim paste works as expected without problems. Seems, that I should address the issue to nvim developers.
claunia commented 2026-01-31 03:26:35 +00:00
Author
Owner
Copy Link

@sisrfeng commented on GitHub (Feb 20, 2022):

+1
Can not find solution in nvim's github.
Anyone has solved it?

@sisrfeng commented on GitHub (Feb 20, 2022): +1 Can not find solution in nvim's github. Anyone has solved it?
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 Needs-Tag-Fix Needs-Triage Resolution-External
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#12848
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?