You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Windows Terminal supports OSC52-base copying but not pasting (for security reasons). Using the new OSC52 support in nvim 0.10 works in Windows Terminal however it is very slow (over 10 seconds). The apparent cause of this is that yanking actually first attempts a paste, which isn't supported and so times out, and only afterwards performs the copy.
Therefore, there is a simple way to resolve this problem for users. Instead of the currently recommended configuration to force OSC52 to be used, instead do the following which makes pasting a no-op (since it wouldn't work anyway):
After doing this, copying is immediate. This seems counter intuitive and I don't understand why the paste function is called when yanking (it appears to be called twice: if you replace my no_paste function with something that prints out, you'll see it).
Presumably, this work around would help any other terminal that supports OSC52 copying but not pasting, apparently including wezterm/alacritty, but I have not tested. See also this discussion: #28010 I have also seen this problem mentioned elsewhere.
Steps to reproduce
Using Windows Terminal, ssh to a machine with neovim 0.10. (Or any other situation where OSC52 is used.) Run nvim and yank a line of text, "+yy. Neovim then hangs for a second and eventually displays a message that it timed out waiting for a response from the terminal.
Expected behavior
Yanking to clipboard should be instantaneous even if paste is not available.
Neovim version (nvim -v)
NVIM v0.10.0-dev
Vim (not Nvim) behaves the same?
No
Operating system/version
Windows 11 (Terminal) / Linux (nvim)
Terminal name/version
Windows Terminal Version: 1.19.10821.0
$TERM environment variable
xterm-256color
Installation
build from repo
The text was updated successfully, but these errors were encountered:
In case anyone ends up here with the same problem, the culprit appears to be the which-key plugin. This displays the contents of various registers when you type ". But that was triggering the OSC52 paste functionality and hanging everything until the paste timed out, even if you only wanted to yank/copy.
Problem
Windows Terminal supports OSC52-base copying but not pasting (for security reasons). Using the new OSC52 support in nvim 0.10 works in Windows Terminal however it is very slow (over 10 seconds). The apparent cause of this is that yanking actually first attempts a paste, which isn't supported and so times out, and only afterwards performs the copy.
Therefore, there is a simple way to resolve this problem for users. Instead of the currently recommended configuration to force OSC52 to be used, instead do the following which makes pasting a no-op (since it wouldn't work anyway):
After doing this, copying is immediate. This seems counter intuitive and I don't understand why the paste function is called when yanking (it appears to be called twice: if you replace my
no_paste
function with something that prints out, you'll see it).Presumably, this work around would help any other terminal that supports OSC52 copying but not pasting, apparently including wezterm/alacritty, but I have not tested. See also this discussion: #28010 I have also seen this problem mentioned elsewhere.
Steps to reproduce
Using Windows Terminal, ssh to a machine with neovim 0.10. (Or any other situation where OSC52 is used.) Run nvim and yank a line of text,
"+yy
. Neovim then hangs for a second and eventually displays a message that it timed out waiting for a response from the terminal.Expected behavior
Yanking to clipboard should be instantaneous even if paste is not available.
Neovim version (nvim -v)
NVIM v0.10.0-dev
Vim (not Nvim) behaves the same?
No
Operating system/version
Windows 11 (Terminal) / Linux (nvim)
Terminal name/version
Windows Terminal Version: 1.19.10821.0
$TERM environment variable
xterm-256color
Installation
build from repo
The text was updated successfully, but these errors were encountered: