pasting large multiline text is extremelly slow

[jmlucjav]

Environment

Windows Terminal Preview v1.6.10272.0 on windows 10 20h2

Steps to reproduce

1. start wt with cmd
2. launch neovim in terminal mode (no gui)
3. enter insert mode with
4. paste a large text, like 200k of json
5. you get the warning about large text being pasted, accept it
6. wait....I had to kill wt, not sure how long I would need to wait (many minutes?)

Expected behavior

the text gets pasted instantly

Actual behavior

you have to wait a lot.

I tried pasting the same text in neovim-qt (the official GUI version of neovim) and the text gets inserted instantly.

I understand pasting large text would be weird in normal terminal usage, but when you are using wt to host neovim it is a legit use case.

[DHowett]

While you're waiting (in step 6), is it actively typing the text into Neovim, or is it just hung?

I ask because it is not a fair comparison between the two. Neovim-qt, because it is a GUI application, uses the clipboard directly. A terminal, on the other hand, has no choice but to communicate the clipboard contents by "typing it in" one character at a time.

If your hang is during active text input, that's just the way things are. If your hang is happening before any text starts to show up, that's probably something we can optimize.

[jmlucjav]

nothing visible is happening while I wait...

[DHowett]

Great! Thanks. That's something we can work with.

[ohroy]

While you're waiting (in step 6), is it actively typing the text into Neovim, or is it just hung?

I ask because it is not a fair comparison between the two. Neovim-qt, because it is a GUI application, uses the clipboard directly. A terminal, on the other hand, has no choice but to communicate the clipboard contents by "typing it in" one character at a time.

If your hang is during active text input, that's just the way things are. If your hang is happening before any text starts to show up, that's probably something we can optimize.

Why the windows terminal is not GUI application? and why it can't use clipboard api..... char one by one is vvvvvvvvvvvvvery slow

[ohroy]

Is anyway to optimize it ??

[muchcharles]

Mine slowly pasted over 30 seconds (just pasting build output from visual studio, around 450 lines), finished, and then hung the whole terminal...

This was pasting into vim in se: paste mode. Finally several minutes later it became responsive.

Text flow in the window became completely broken, with the upper half empty, even if I background or close vim and do ctrl+l or run clear. It seems to be a terminal reflow problem and not something inside WSL.

[ngoc199]

I have pasted 117 lines of code into Neovim and the Terminal freezes. I think it should be pasted immediately, but it's not.

I have to close it using Task Manager after waiting a minute.

Do you have any idea to solve this issue?

[zadjii]

@zadjii-msft note to self, this might be related to that other neovim hang thread.

The theory had something to do with someone else taking the clipboard lock. win32-clip.exe? Can't remember the details at 3am.

[jmlucjav]

For myself, this has improved a lot with newer versions of terminal, I'm on latest preview. Even if it is not instant, it is okish.

[impworks]

Having the same problem with Far Manager running in Windows Terminal.
When using the "legacy console" mode, copying and pasting is instant. When switching to the new one, it's excruciatingly slow - and also pops up two warnings which in this particular case are pointless.

[Tillerz]

This is still a serious problem. Using any of the shells, command prompt or power shell, if you are working in those text windows and paste in text, you can just watch how the text is pasted in slowly. And I have a really powerful machine.

My guess is that this formatting filter that is applied before pasting is just really really bad coded and quite slow.

I work a lot with text files and jump around in folder using tools like FileCommander. Those are not really usable anymore on Windows 11. And it's a pain to open each file in a separate editor, that's not running inside that command shell.

And as impworks said, the legacy console is as fast as it should be. But once this console is gone, then we'll have a problem.

[VasyaSh]

Expected behavior

the text gets pasted instantly

@ngoc199 @impworks @Tillerz I found a solution for console software like Far Manager, etc. Seemly the slowing down is caused by the Windows Terminal which is an "emulator" over native PowerShell (in my understanding).
Anyway, copy/pasting performance issue can be fixed by running those applications on Windows Console Host instead of the terminal. How to switch on WCH on Windows 11:

1. Right click on Start button
2. Click "Settings"
3. Go "Privacy & Security"
4. Within the Security section, click "For Developers"
5. Switch Terminal from "Let Windows Decide" to "Windows Console Host".

That's it, after this tweak my Far Manager look and works as in old times.

[LakshmanKishore]

This issue still exists.
I tried switching the terminal from "Let Windows Decide" to "Windows Console Host", it had no effect.

The paste is very slow.

[zadjii-msft]

That's surely an interesting observation! If you're finding that pasting is slow in both conhost and Terminal, that seems like it would suggest that the issue is in the neovim implementation itself, right? Perhaps there's something in your config that's slowing it down?

Almost everyone else in this thread seems to have an issue specifically with Terminal's paste implementation. That just makes it feel like what you're seeing is ultimately a different root cause.

[LakshmanKishore]

You are right @zadjii-msft.
I used to connect to a remote server via SSH in the Git Bash profile of the Windows Terminal, but the pasting speed was very slow. Then I discovered that I could create a new profile with the SSH command directly in the command line. This improved the pasting performance slightly.

[xparq]

... that the issue is in the neovim implementation itself ...

Not really. I've never used neovim, and copy/paste was staggeringly slow for me, too. It was truly unbelievably slow, frankly, with everything I tried. It was impossible to use for me at that time (sorry, no records of details, and I'm away from my desktop now).

OTOH, interestingly, I've also noticed this extreme pasting slowdown even when supposedly using ConHost -- but only after trying the new Terminal, never before. So I got totally perplexed. Had to give up investigating it further, with my limited understanding (of this subsystem and its various interop. cases, dependencies etc.).

[lhecker]

I feel like there can be multiple issues at play here and we need to be careful not to mix them up.

• If you use the builtin clipboard functionality of nvim, that is with "+p or with
  
  and it's slow, then it's unrelated to this issue and should be reported to nvim.
• If pasting lags a lot even for small files (<1000 chars) then it's likely that another application is holding the clipboard lock, which can happen, especially via RDP. That one can also not be solved by us, because it's inherent to Windows.
• If pasting "large" amounts of text (>1000 chars) in nvim without the builtin clipboard handling, then it's partially on us (~10%) and otherwise on nvim (or rather on libuv specifically).
  • On our side the slowdown is because pasted text is converted to key events character by character and put into a ring buffer in the InputBuffer class so that applications can later retrieve them. That is, for a 1MB text file we'll generate 2M up/down KeyEvents and put them into a buffer. Improvements have been made in that area recently, but it's still really bad: For a 230KB file, this still takes about an entire second.
  • In case of nvim (libuv) this is because they read input one character at a time: https://github.com/neovim/libuv/blob/c124607c8893126f2e769c30e03f5d8d665f46a2/src/win/tty.c#L806-L809
    Obviously, that's anything but optimal. 😅 Unless the buffer size is increased there, reading large amounts of input data will remain extremely slow.
• If pasting is slow in Windows Terminal, but not in conhost/OpenConsole, then this is likely resolved with Replace WinRT clipboard API with Win32 for pasting #15360 if it's still an issue nowadays. (There was a process priority fix that shipped earlier this year that might have fixed this issue as well.)
• If pasting large amounts of text is slow in another application (not nvim) then please check the size of the ReadConsole or ReadConsoleInput calls. If they're small, then try increasing them.
• Otherwise, if pasting large amounts of text, it's not nvim, it's not a small ReadConsole/ReadConsoleInput buffer size and it's slow in both Windows Terminal and conhost, then please let us know. It'd be great if you could include precise reproduction steps.

[xparq]

FWIW, several Win10 updates later, I've quickly tried to reproduce the issue, and failed. Across Win - Win, across WSL - Win, WSLg - Win, whatever I tried today, it's smooth.

For clarity, regarding @lhecker's list: "If pasting lags a lot even for small files (<1000 chars)" -- that was my main use case. It's possible, indeed, that something had locked the clipboard (but I vaguely recall really basic, dummy use cases, when it still happened).

But now that we talk, I can recall another case from earlier this week, when it was a substantially larger amount of text, and it was not just slower, but I had to kill the stuck process minutes later.

Unfortunately, I was not trying/equipped to gather data, and all my memories are vague now, but I'll try to keep an eye open then, and get back if I have anything useful.

[vazmiguel]

For anyone interested you can fix slow pasting in Windows Terminal for PowerShell console windows by commenting out command paste lines in Windows Terminal settings.json for immediate pasting. Execution will only trigger after all lines are pasted.

Note: This solution is specifically for PowerShell console windows as it uses separate KeyHandlers for Ctrl+V, in PSReadline module.

Try commenting out these in WT settings.json, i.e:

    // {
    //     "command": "paste",
    //     "keys": "ctrl+v"
    // },

You might also want to consider disabling paste warning as well, as in:

"multiLinePasteWarning": false,
"largePasteWarning": false,

[brookst]

Just ran into the issue with Microsoft.WindowsTerminal.Preview 1.19.2831.0
Pasting a lot of text into NVim v0.6.1 under WSL hung the terminal. The warning about more than 5KiB of text came up, and on pressing the "Paste anyway" button, the whole thing froze - the dialog box didn't even close. Eventually (order of minutes) the title bar stopped rendering and fell back to the default Windows title bar. I waited (order of minutes) but had to kill the terminal with the "not responding" dialog after trying the close button. That took all my open tabs with it.

Surely if there is some kind of lock contention over the clipboard, the operation should just time out and abort the paste operation? Better to fail than crash all terminals trying to complete the action.

[lhecker]

@brookst Thanks for the report! It's a bug that I've recently caused and so far we weren't really aware about it. I'll open a PR in a bit.

[brookst]

Yeah, I think it's different. After restarting, I can paste the same quantity of text fairly quickly. I think there must have been something else up with the system. DWM had leaked a load of memory and been restarted - could have been some interaction with that.

One (separate) issue I do notice now is that the paste doesn't go through until I input another keypress, then it's sent after that keypress. So I have to send a new line or else it just sits there. This only seems to affect NVim though - pasting into, say, bash works fine.

[lhecker]

What amount of text are you pasting? I found the issue you described initially to be easily reproducible if I paste a ton of text at once (i.e. 1MB in this case). I think whether it deadlocks or not depends on a ton of circumstances, for instance on how nvim processes its input (i.e. it only happens if nvim redraws rapidly while also reading its input at the same).

[brookst]

Hmm, using some random plain text from the terminal itself into nvim, it's fine at the end of a file. Even above the 5KiB warning, it pastes instantly. However I can reproduce the lock-up if the paste occurs within a line of existing text.

Pasting in a piece of rich-text from a Windows application (happens to be Zotero in this case, but can also be from notepad which I guess has pre-stripped any rich-text-ness) into nvim (starting with an empty buffer) locks up the terminal and crashes it immediately. Pasting into the terminal itself seems to work ok. Copying the text back from the terminal into nvim causes the same lock-up.

This text is ~80KiB and has a substantial amount of (non-ASCII) unicode in it. Portions of the text do not cause the same lock up, but I can't narrow down how much of it is needed to cause the lock-up (it seems to need all of it to reproduce the issue).

So it seems like something neovim is doing with non-trivial input (mid-line paste, long-lines, unicode). This somehow takes out the terminal with it.

I don't think that narrows it down exactly, but it is reproducible. I need to get on with other things and stop crashing my terminal now.

I can't reliably reproduce the 'waiting for input before the paste takes effect' issue at this time.

[croc541]

Having the same problem with Far Manager running in Windows Terminal. When using the "legacy console" mode, copying and pasting is instant. When switching to the new one, it's excruciatingly slow - and also pops up two warnings which in this particular case are pointless.

I've experienced the same issue with Far Manager in WT (created a new profile for it). Even pasting a few dozen lines was taking a few seconds (I could see lines appearing one by one on the screen). I tried the suggestion to comment out the following block in the settings.json:

// {
//     "command": "paste",
//     "keys": "ctrl+v"
// },

and now I can paste arbitrary amounts of text instantly. This was also enough to suppress all warnings about multi-line paste.

[anta999]

Having the same problem with Far Manager running in Windows Terminal. When using the "legacy console" mode, copying and pasting is instant. When switching to the new one, it's excruciatingly slow - and also pops up two warnings which in this particular case are pointless.

I've experienced the same issue with Far Manager in WT (created a new profile for it). Even pasting a few dozen lines was taking a few seconds (I could see lines appearing one by one on the screen). I tried the suggestion to comment out the following block in the settings.json:

// {
//     "command": "paste",
//     "keys": "ctrl+v"
// },

It might not work.
Open Settings - Actions - move to trash all key binds 'paste'

[rhrusha]

Having the same problem with Far Manager running in Windows Terminal. When using the "legacy console" mode, copying and pasting is instant. When switching to the new one, it's excruciatingly slow - and also pops up two warnings which in this particular case are pointless.

I've experienced the same issue with Far Manager in WT (created a new profile for it). Even pasting a few dozen lines was taking a few seconds (I could see lines appearing one by one on the screen). I tried the suggestion to comment out the following block in the settings.json:

// {
//     "command": "paste",
//     "keys": "ctrl+v"
// },

and now I can paste arbitrary amounts of text instantly. This was also enough to suppress all warnings about multi-line paste.

Works great for me! Thank you.