pasting large multiline text is extremelly slow #12664

@ohroy commented on GitHub (Feb 24, 2022):

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 commented on GitHub (Feb 24, 2022): > 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

claunia commented

@ohroy commented on GitHub (Feb 24, 2022):

Is anyway to optimize it ??

@ohroy commented on GitHub (Feb 24, 2022): Is anyway to optimize it ??

claunia commented

@muchcharles commented on GitHub (Mar 25, 2022):

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.

@muchcharles commented on GitHub (Mar 25, 2022): 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.

claunia commented

@ngoc199 commented on GitHub (Dec 18, 2022):

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?

@ngoc199 commented on GitHub (Dec 18, 2022): 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?

claunia commented

@zadjii commented on GitHub (Dec 18, 2022):

@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.

@zadjii commented on GitHub (Dec 18, 2022): @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.

claunia commented

@jmlucjav commented on GitHub (Dec 18, 2022):

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.

@jmlucjav commented on GitHub (Dec 18, 2022): 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.

claunia commented

@impworks commented on GitHub (Jan 20, 2023):

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.

@impworks commented on GitHub (Jan 20, 2023): 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.

claunia commented

@Tillerz commented on GitHub (Jan 20, 2023):

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.

@Tillerz commented on GitHub (Jan 20, 2023): 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.

claunia commented

@VasyaSh commented on GitHub (Mar 25, 2023):

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:

Right click on Start button
Click "Settings"
Go "Privacy & Security"
Within the Security section, click "For Developers"
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.

@VasyaSh commented on GitHub (Mar 25, 2023): > # 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.

claunia commented

2026-01-31 03:21:36 +00:00

@LakshmanKishore commented on GitHub (Aug 8, 2023):

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.

@LakshmanKishore commented on GitHub (Aug 8, 2023): 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.

claunia commented

@zadjii-msft commented on GitHub (Aug 8, 2023):

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.

@zadjii-msft commented on GitHub (Aug 8, 2023): 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.

claunia commented

2026-01-31 03:21:36 +00:00

@LakshmanKishore commented on GitHub (Aug 26, 2023):

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.

@LakshmanKishore commented on GitHub (Aug 26, 2023): 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.

claunia commented

2026-01-31 03:21:36 +00:00

@xparq commented on GitHub (Aug 26, 2023):

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

@xparq commented on GitHub (Aug 26, 2023): > ... 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.).

claunia commented

@lhecker commented on GitHub (Aug 26, 2023):

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: c124607c88/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 #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.

@lhecker commented on GitHub (Aug 26, 2023): 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 ![image](https://github.com/microsoft/terminal/assets/2256941/2e2f0812-1598-445b-b825-45a5d6123f52) 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 `KeyEvent`s 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 #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.

claunia commented

@xparq commented on GitHub (Aug 27, 2023):

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.

@xparq commented on GitHub (Aug 27, 2023): 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.

claunia commented

@vazmiguel commented on GitHub (Oct 4, 2023):

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,

@vazmiguel commented on GitHub (Oct 4, 2023): 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,

claunia commented

@brookst commented on GitHub (Oct 24, 2023):

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.

@brookst commented on GitHub (Oct 24, 2023): 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.

claunia commented

@lhecker commented on GitHub (Oct 24, 2023):

@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.

@lhecker commented on GitHub (Oct 24, 2023): @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.

claunia commented

@brookst commented on GitHub (Oct 24, 2023):

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.

@brookst commented on GitHub (Oct 24, 2023): 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.

claunia commented

@lhecker commented on GitHub (Oct 24, 2023):

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

@lhecker commented on GitHub (Oct 24, 2023): 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).

claunia commented

@brookst commented on GitHub (Oct 24, 2023):

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.

@brookst commented on GitHub (Oct 24, 2023): 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.

claunia commented

2026-01-31 03:21:39 +00:00

@croc541 commented on GitHub (Oct 30, 2023):

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.

@croc541 commented on GitHub (Oct 30, 2023): > 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.

claunia commented

@anta999 commented on GitHub (Jan 24, 2024):

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'

@anta999 commented on GitHub (Jan 24, 2024): > > 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'

claunia commented

2026-01-31 03:21:39 +00:00

@rhrusha commented on GitHub (Apr 25, 2024):

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.

@rhrusha commented on GitHub (Apr 25, 2024): > > 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.

claunia commented

2026-01-31 03:21:39 +00:00

@inzeets commented on GitHub (Oct 26, 2025):

What's the matter with my paste being sos low? is it being sent to some cloud by default?

@inzeets commented on GitHub (Oct 26, 2025): What's the matter with my paste being sos low? is it being sent to some cloud by default?

claunia commented

@lhecker commented on GitHub (Oct 27, 2025):

To be honest, if you have some sort of enterprise AV it may actually get sent somewhere.
I can't say that I've seen it be extremely slow myself yet, otherwise I would've investigated it.

@lhecker commented on GitHub (Oct 27, 2025): To be honest, if you have some sort of enterprise AV it may actually get sent somewhere. I can't say that I've seen it be extremely slow myself yet, otherwise I would've investigated it.

claunia commented

@xparq commented on GitHub (Oct 27, 2025):

... I'll try to keep an eye open then, and get back if I have anything useful.

Happened again recently, out of the blue.

Since I've also seen the same bizarre slo-mo terminal output in a totally different context (during a build, with the CPUs nearly maxed out), I suspect it's a threading issue: as if the terminal yielded the thread per-char, instead of doing a batch of work with a whole bunch of them.

@xparq commented on GitHub (Oct 27, 2025): > ... I'll try to keep an eye open then, and get back if I have anything useful. Happened again recently, out of the blue. Since I've also seen the same bizarre slo-mo terminal output in a totally different context (during a build, with the CPUs nearly maxed out), I suspect it's a threading issue: as if the terminal yielded the thread _per-char_, instead of doing a batch of work with a whole bunch of them.

claunia commented

@lhecker commented on GitHub (Oct 27, 2025):

That is a possible cause that we've been tracking. As you may know, if you spawn CLI apps outside of Windows Terminal, they'll still open inside Windows Terminal anyway (example: you search "cmd" in the start menu and launch it). But if you look at the process tree, you'll see that cmd.exe will not be a child process of WindowsTerminal.exe. Only if CLI apps originally launched from inside Windows Terminal (as a profile) will it be child processes.

The second problem is that the Windows process scheduler is (to my knowledge) known to be "imperfect", put mildly. It gives the current foreground process a priority boost over all other processes. If you focus Windows Terminal, then WindowsTerminal.exe and all of its child processes will get that boost. Since those CLI apps launched outside of Windows Terminal are not child processes they won't get boosted. The scheduler could follow the dependency chain formed by the IO pipes but it doesn't. And so, your CLI apps may start lagging severely if your CPU is 100% loaded, because those alleged "background processes" are throttled.

The theoretical solution for that is #19192. To my knowledge the feature backing this (56023428) has been broadly rolled out in the Windows 11 2503 update.

@lhecker commented on GitHub (Oct 27, 2025): That is a possible cause that we've been tracking. As you may know, if you spawn CLI apps outside of Windows Terminal, they'll still open inside Windows Terminal anyway (example: you search "cmd" in the start menu and launch it). But if you look at the process tree, you'll see that cmd.exe will not be a child process of WindowsTerminal.exe. Only if CLI apps originally launched from inside Windows Terminal (as a profile) will it be child processes. The second problem is that the Windows process scheduler is (to my knowledge) known to be "imperfect", put mildly. It gives the current foreground process a priority boost over all other processes. If you focus Windows Terminal, then WindowsTerminal.exe and all of its child processes will get that boost. Since those CLI apps launched outside of Windows Terminal are not child processes they won't get boosted. The scheduler _could_ follow the dependency chain formed by the IO pipes but it doesn't. And so, your CLI apps may start lagging severely if your CPU is 100% loaded, because those alleged "background processes" are throttled. The theoretical solution for that is #19192. To my knowledge the feature backing this (56023428) has been broadly rolled out in the Windows 11 2503 update.

claunia commented

@inzeets commented on GitHub (Jan 7, 2026):

Stable way to reproduce: run FAR manager in wt, open new file for editing (Shift+F4), and paste. Could Copilot make its research and fix it?

@inzeets commented on GitHub (Jan 7, 2026): Stable way to reproduce: run FAR manager in wt, open new file for editing (Shift+F4), and paste. Could Copilot make its research and fix it?

claunia commented