BufferHeight causes a delay when opening/closing apps that use alternate screen (eg vim, nano, etc)

[telamonian]

Versions

ConEmu build: 171226 x32/x64 (tried with both)
OS version: Windows 10 x64
Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): bash (WSL)

Problem description

Whenever I open or close a file using vim there's a delay of several seconds. Other apps that use the alternate screen mechanism (such as nano) seem to have the same problem as well. Turning off the BufferHeight option by pressing the related button on the tab bar fixes the issue, but then I lose all scrollback.

Steps to reproduce

1. Install WSL, Ubuntu (from the MS store), and ConEmu.
2. Open any file using the vim or nano commands that ship with the Ubuntu instance from the MS store.

Some notes/observations

• When I close a file in vim, there's first a slight delay, then the terminal screen loses all color and goes black and white, and then there's a longer delay before vim finally quits. Not sure if that's a helpful detail for tracking down the issue, but it is pretty weird.

• The Real console (from the debug menu) has slightly different behavior from the actual ConEmu console. When opening a file with vim, both the Real and the ConEmu consoles hang for a couple of seconds. However, when I close vim it closes instantly in the Real console, whereas the ConEmu console hangs again for a couple of seconds.

[telamonian]

Just tried upgrading to the latest vim, but it didn't help. Figured it was worth a shot

[toddjames]

Same problem here. Is there any workaround for launching nano in a way that doesn't lag the console? This is the last thing preventing me from switching from Cygwin to WSL.

[dypsilon]

Same issue here. Running less ~/.bash_history produces a 1-2 seconds delay on open and on close. No delay in basic bash.exe running without ConEmu.

[jared-is-ray]

I also notice this same behavior when running vim/less over ssh. I see a long pause when opening these programs. If I disable the BufferHeight I no longer see the pause.

ConEmu version: 180617 (with flags -cur_console:p)
SSH for Windows Version: 7.6.1.0p1-Beta
Windows Version: 10 - 1803 Build 17692.1000

[gc435]

I can confirm the same delay happens for me, and there is no delay when bufferheight is turned off.

ConEmu 180626
Vim 8.0.604

[tshafeev]

Can confirm it too.
WinVer 1803 Build 17713.1002
ConEmu 180626
Vim 8.0.604
mc
less

[Maximus5]

Work on new pty interface is in progress

[agnf]

I can confirm the same delay happens for me, and there is no delay when bufferheight is turned off.

ConEmu 180626

[Rohaq]

Getting the same issue inside cygwin too. Opening and closing things like emacs has an extremely noticeable delay of 1-2 seconds with Bufferheight enabled.

ConEmu 180626 preview

[unhuman]

Disabling (unchecking) bufferheight doesn't work for me, but changing the value to something smaller does...

I've found that using smaller values (say 3000) seems to be a decent compromise until there's a fix.

[zxbuaa]

Same issue to me.
ConEmu 180626

[hopeday6688]

Same issue to me.
ConEmu 180626

[Brassfield]

Problem Continues - ConEmu64 190108

The delay between Debug's RealConsole and default ConEmu (60k lines of buffer?) was about 3 seconds, or 50% when shutting down aptitude.

Cutting /Gen/Size&Pos/Size/Console Buffer Height to 5K significantly decreases the delay.

[bsdelf]

Exactly the same issue (observation 1).

• version: 190303
• task: conemu-cyg-64.exe --wsl -t zsh

[Maximus5]

gh-1841

[toddjames]

For anyone else simply looking for a Linux shell experience on Windows with WSL and was hoping to use ConEmu + WSL, I found an alternative solution that works well for me. I had given up on ConEmu due to this issue (sorry, @Maximus5 , but I do thank you for all of your work on this project.. I used it for a few years).

You may want to check out X410 in the Microsoft Store. It's usually $10 (and almost always "on sale"). You can use a native Linux terminal like Tilix or GNOME terminal with WSL. Just make sure to follow their tutorials on their website for setup (including running sudo commands as yourself, not as root). I'm not affiliated or anything - just another person looking for a Linux shell experience on Windows with WSL.

[Maximus5]

190310?

[bsdelf]

190310?

The issue is gone. Thanks for your work.

[bsdelf]

With 190310, actions like close vim, ctrl-z, fg is fluent now.

While in tig, pressing j to scroll down still has noticeable renderer latency (compared with vscode's wsl console). However, it might be another issue.

[Maximus5]

tig problem is not related to this issue. Please fill new one

[dzek69]

Any progress update or some ETA on this one?

Thanks for your work so far.

[Maximus5]

@dzek69 What are you asking about? The issue is closed, ETA is zero.

[dzek69]

Oh, sorry, it was closed just few hours ago and I missed that. Just upgraded and looks like it isn't slow anymore. Thanks.

[johncrane]

I am still experiencing the same issue today.
Version 191012 preview
After decreasing Buffer Height to 3000, open vim is much faster. But closing vim still takes long time.
I am wondering if there had been regression recently.

[SebastianDix]

Experiencing the same issue today with 201124

[bytefluxio]

I'm not sure how exactly it was behaving before, but there is a ~2sec delay opening and closing vim for me. :'(

for comparison, with bufferheight off:

[Maximus5]

@bytefluxio How exactly do you start wsl?
Delay comes out of storing full contents of console (with backscroll buffer), but when you run "wsl.exe" directly (without connector), ConEmu does not process any ANSI sequences at all, so it does not handle buffer switching.

[bytefluxio]

@Maximus5 sorry i missed your reply. I start using the following:

I hope I didn't misunderstand your question.

So I'm guessing I'm doing something wrong :(

[Maximus5]

@bytefluxio That's amazing...
I see on your screenshots that terminal mode is changed from "X" to "XAB" and back when you start/exit the vim.
I wonder how it's possible. When you run wsl.exe that way (as in your Ubuntu task), wsl.exe does not send any ANSI sequences to ConEmu.

So I have more questions

1. Could it be that you start vim.exe (native Windows binary)? Please check your process tree with ProcessExplorer or ConEmu Settings/Info page.
2. Which Windows version do you use?
3. Which Ubuntu distro do you use?
4. What is your vim configuration? Could you share your vimrc?

The automatic change to "XAB" is unexpected when you run "wsl.exe" directly without Connector. And that is a big problem because arrow keys aren't working as expected in WSL. So, I wonder how that change happens on your PC?

Could you turn on the "Log console output" and "Internal LogFiles location" checkboxes in Settings, after that start new WSL tab, reproduce the problem (start/exit Vim) and attach here generated log files (from both locations).

[bytefluxio]

@Maximus5:

1. Doesn't seem to be vim.exe

Edition	Windows 10 Home
Version	Dev
Installed on	‎27.‎05.‎2021
OS build	21390.1
Experience	Windows 10 Feature Experience Pack 321.13302.10.3

Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:        20.04
Codename:       focal

4. Vimrc: https://gist.github.com/bytefluxio/af86f8697f15b16ddd285322aaa215b7

5. Logs from both locations. Once while bufferheight was on and once off:
   ConEmuLogs-Bufferheight-On.zip
   ConEmuLogs-Bufferheight-Off.zip

PS: Since the gif, I have changed shells form zsh to fish and its a little faster now, but so is everything. the vim thing is still the worst :(

[BlueSky-07]

@bytefluxio Hey, I got the same problem. Both vim.exe(8.2.2859) in Windows(21H1 19043.1055) and vim(8.1.2269) in WSL2(Ubuntu 20.04.2) there is a ~2sec delay opening and closing, but using Windows Terminal(1.8.1521.0) or PowerShell(7.1.3) will not. I found uncheck "Inject ConEmuHk.dll into all processes started in ConEmu tabs" in Settings can solve this problem. (ConEmu 210422)

[yclian]

@BlueSky-07 's suggestion to uncheck "Inject ConEmuHk.dll" did the trick for me too.

[piszczek]

@BlueSky-07 this trick also works for me, thx 🙏