Windows Terminal Preview Bugs with VIM
CodemonkeyWTF March 2021
The Windows Terminal is a modern, fast, efficient, powerful, and productive terminal application for users of command-line tools and shells like Command Prompt, PowerShell, and WSL. Its main features include multiple tabs, panes, Unicode and UTF-8 character support, a GPU accelerated text rendering engine, and custom themes, styles, and configurations.
disclaimer: I've been using Linux for over 20 years, and Windows 10 for about 8 months (off and on, more on than off lately).
This is a stupid bug, one that's been around for a very long time and it possibly only effects Vim. NeoVim or nvim works fine when the circumstances that cause this issue are in play. It's frustrating, and it's probably more of an issue with Vim than with Windows Terminal.
So what is this bug that had me on the verge of giving up on Windows? I like a good story, and I often like to get to the point in a round about way. This won't take long, and the solution is simple enough anyway. It's so simple in fact, I'll give you the solution before I tell the story, if you don't feel like reading for an extra few minutes.
The Solution!
when using Windows Terminal don't set your DISPLAY with .bashrc or .profile UNLESS you are going to always run an Xserver like Xming
When I use Windows 10, which happens to be most of the time these days, I use Windows Terminal. I use it a lot! It's on par with kitty, which has been my default Linux terminal for a little while now. It's very configurable with color tabs, background images and transparency, custom themes, and panes. Oh, you can run wsl2, cmd, and powershell in different panes under the same tab. I use wsl2 about 99.999% of the time. I use vim as my code editor more than I use vscode. Mostly because I'm lazy and it's much easier to quickly edit a bit of code with vim, at least for me.
So what happened? I needed to edit a bit of code and... vim wouldn't open. Suddenly I felt like I was having a staring contest with a cat, and the cat was winning. Vim didn't pop open instantly, it didn't pop open 30 seconds later, I was losing hope that it would ever open. I started to think the terminal locked up, which hadn't happened for a long while... yes I've had Windows Terminal go into some strange electronic coma more than a few times and I had to shut it down and re-open it. Frustrating for sure. I don't know exactly how long it took, but whatever was happening eventually vim opened. Something still seemed wrong because moving around in vim was uncharacteristically slow. I had more work to do, so I tried to open another file to edit. Same thing, right back to the cat staring contest!
What now? Now it was time to trouble shoot the situation and try to figure out why vim was suddenly broken. Windows 10 had updated the night before, so naturally my first thought is something unexpected changed in the update. Time to google vim slow in windows terminal. Most of the links were from 2016, surely anything from 2016 would have been resolved by now. I scanned though the search results looking for something recent. There wasn't anything current, so maybe it's not from the recent update after all. Of course now I have to go dumpster diving, looking through a bunch of unrelated stuff. I happened to see a few things related to using an Xserver, but I wasn't running an Xserver at the time so I mostly ignored them and found some trouble shooting things to try. I did find a vim flag
$ vim --startuptime vimlog.txt
that lets you make a logfile of vim's startup. It looked like it was hanging on plugins, so disabled all of them. Nope, vim was still not working.
The next logical step? I rage quit Windows 10! I needed to get some things done, so I shut down Windows and booted into my Linux drive. I spent too much time trying to get things working instead of actually working. Once I had some free time I rebooted back into Windows, mostly because VirtualBox wasn't working for some reason, something else I'm going to have to troubleshoot later. I wanted to see if the reboot might have magically fixed the problems I was having, but alas, turn it off and back on again didn't resolve the issue. Back to google to see if I could find something... anything... I noticed the search result that suggested that it's some sort of Xserver issue. In a nutshell it said that vim is looking for DISPLAY, and if you have a DISPLAY set that vim can't reach then it's going to hang. I don't usually run an Xserver, but I was trying out a new dotnet thing called Photino. It wasn't working, basically it's currently a preview release (interestingly though, the preview works great in Linux). That's why I was using an Xserver. I added a little script to my .bashrc to set the output to the current IP address (wsl2 doesn't always have the same IP address between bootups).
The solution... again. I commented out the lines in my .bashrc that set DISPLAY. I restarted Windows Terminal and life is back to normal!
The moral of this story... Don't set DISPLAY in a script when using vim in wsl2 unless you know you are going to always run an Xserver.
You made it to the end! Thank you for reading this far.
Top comments (1)
I totally feel your pain. I was in the similar situation, but back then the wsl1 was quite bad. I used vim in normal windows cmd but for some reason it was much slower than on Linux (especially bigger files, not to mention if I added some plugins).
In WSL it was better but I had to run it without Xserver as it was just too slow in the corporate environment. My suspicion was that the firewall we had was slowing it by checking every request to the server
I also learned that windows is not settings the TERM variable. It was a problem for some terminal apps while others kept crashing when it was actuall set. So I had to set it and unset it when I ran some utilities (ssh, lf etc).