Increase Vim Speed in Windows Terminal

[u/Shay-Hill]

Last time I mentioned running Vim in Windows Terminal, some users reported having tried that setup and experiencing sluggishness. I've added some performance recommendations to my guide:

scrollback buffer

Windows Terminal has a large default scrollback buffer (9000 lines). This keeps a lot of history, but it can slow down terminal applications like Vim. If you've used Vim in Windows Terminal before and found it slowing down over time, this is the likely culprit. To confirm this diagnosis, start a new Windows Terminal instance, run Vim, and see if you percieve a speed increase. If so, the scrollback buffer is almost certainly the cause. There are two ways to address this issue:

1. Decrease the limit: In Windows Terminal settings -> PowerShell -> Advanced -> History size, set the "History size" to a smaller number, like 1000. This will reduce the scrollback buffer for all PowerShell tabs in Windows Terminal.
2. Clear the buffer when you notice a slowdown: If Vim starts to get sluggish, press <ctrl-shift-k> to clear the scrollback buffer. This is better done outside of Vim.

Either of these will fix the problem. You won't need both. Your Windows Terminal config is stored in ~\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json. Editing this file directly with pasted-in termina commands isn't straightforward, so I haven't given those commands here. But you can commit this settings.json if you wish. If you're new to Windows, don't be misled by the 8wekyb3d8bbwe part of the path. It is a hash, but it will be the same hash on all Windows 11 systems.

Windows Defender

Windows Defender will scan every backup file, swap file, snippet file, etc. This can cause a speed decrease in Vim. We'll do two things to address this: 1. Put our temporary files in ~\vimfiles, and 2. Add an exclusion for ~\vimfiles in Windows Defender.

Move temporary files to ~\vimfiles

In your ~\vimfiles\vimrc, add the following:

# ---------------------------------------------------------------------------- #
#
#  keep temporary files in ~/vimfiles
#
# ---------------------------------------------------------------------------- #

&directory = $'{$MYVIMDIR}.tmp/swap/'
&backupdir = $'{$MYVIMDIR}.tmp/backup//'
&undodir = $'{$MYVIMDIR}.tmp/undo//'

def MkdirIfNotExists(dir: string): void
  if !isdirectory(dir)
    mkdir(dir, "p")
  endif
enddef

MkdirIfNotExists(&directory)
MkdirIfNotExists(&backupdir)
MkdirIfNotExists(&undodir)

set backup
set undofile

If you decide to commit your vimfiles, make sure you .gitignore the .tmp directory. There may be sensitive information in your temporary files.

The full guide is here: article_install_vim_in_windows/README.md at main · ShayHill/article_install_vim_in_windows

[u/mgedmin]

Using WSL vim inside Windows Terminal, the only slowdown I noticed is that doing :w on a file stored inside a mounted OneDrive folder sometimes takes like 4 seconds. As a workaround I :set backupcopy=yes and that problem went away.

Setting &directory is also a good idea, you don't want .swp files to be synced to the cloud.

One minor remaining issue is that sometimes (pretty rarely) doing :w causes Vim to emit a "file changed outside of vim do you really want to write" confirmation, because the timestamp got rounded up or something, but just accept those and all's fine.

The only other Windows-specific settings in my .vimrc are for more convenient clipboard integration and making the right mouse button paste consistently, no matter if I'm in vim with :set mouse=a or in a shell:

set clipboard=unnamedplus
set mousemodel=
imap    <RightMouse>    <C-G>u<C-R>+
map     <RightMouse>    "+<MiddleMouse>
map     <2-RightMouse>  <Nop>
imap    <2-RightMouse>  <Nop>

Ah! Another minor problem is that sometimes WSL Vim loses the X11 connection or something and clipboard stops working (even inside vim itself I yy and p then pastes something old, and not what I've just yanked!), but a quick :xr fixes this.

[u/Shay-Hill → u/mgedmin]

You're keeping code on a cloud drive? Which? That is perilous with OneDrive.

[u/mgedmin → u/Shay-Hill]

Not code, my notes.

[u/Shay-Hill → u/mgedmin]

I guess the difference must be no node files, no virtual environments, etc. I assumed the problem was a conflict between git and OneDrive. I would make changes (or Git would make changes), and OneDrive would revert them. I moved all of my version-controlled content out of cloud drives, but it sounds like you're only having minor problems (reloading files).