My .vimrc and .gvimrc

Vim9 script

I rebuilt my .vimrc and .gvimrc as Vim9 script in July/August 2023. That was a valuable exercise because it helped me purge unused things. It also de-cluttered because I’d made the Vim script version handle all sorts things back to 7.x (which is now deprecated, though still handled in the _vimrc8 and _gvimrc8 files).

Structure

Note	With Vim9 script allowing an initial Vim script section (vim9-mix), the 2023 approach was to have the .vimrc only source .vimrc8 and, if applicable, .gvimrc8 when the version was before 8.2.3434. That has been discontinued now that it is very rare to need to use versions before that.

For version 9 (or 8.2.3434 onwards, where Vim9 script works adequately for .vimrc purposes) the applicable files are .vimrc and .gvimrc. They have been designed to work in Windows 11, WSL Debian, and Debian 13, with renaming _vimrc and _gvimrc when used with Windows 11.

Version and patch	Use	Loads (GUI)
gVim 900 or >=802 patch 3434	.vimrc	.gvimrc
vim 900 or >=802 patch 3434	.vimrc
gVim <802 patch 3434	_vimrc8	_gvimrc8
vim <802 patch 3434	_vimrc8

Note	To use versions <8.2.3434, rename the _vimrc8 and _.gvimrc8 by removing the 8. If need be, rename the _vimrc and _gvimrc by appending a 9 first.

The files may be used by Linux and WSL and, because the . files have been built for either Windows or Linux/WSL, a symbolic link either from or to the . versions works well.

There are only a few things in the Vim9 script .vimrc that are not compatible with versions before the version 9.0.x. However, it is possible to utilise features in later versions as they come up. In those instances it is necessary to make those only called with a has('patch-N.N.NNNN') conditional test. An example is the option cdhome, which was not available until version 8.2 with patch 3780:

if has('patch-8.2.3780')  # v:versionlong >= 8023780
  set cdhome
endif

If the GUI is not needed, using .vimrc directly in the $HOME directory is the simplest approach. For example, if using Windows Git Bash, just use the .vimrc as-is.

There are some conditional sections to handle the differences, though those are mostly around display.

GUI - Windows and gtk-3

From 2023-07-15, I separated most of the GUI-specific things into .gvimrc, which was driven by making a specific Toolbar for gVim. It is also the recommended way of keeping GUI-related settings distinct. This has grown further, but it is still nowhere near as large as the .vimrc.

One consideration around this is the order of loading of plugins. Reviewing output of --startuptime, the following is seen, in this order:

• The ftdetect folder-containing plugins (e.g., in vim-asciidoctor) sourced by _vimrc are loaded first along with other vim91 folder .vim files (e.g., syntax.vim)

• The $HOME\.vimrc is next, which is followed by its packadd \opt folder plugins.

• Other vim91 folder plugins are next (e.g., netrwPlugin.vim).

• The $HOME\.gvimrc is almost last, sourced just before the GUI starts.

What this means is that setting things in the $HOME\.gvimrc needs to be considered in the context of the things that could impact that which have already been loaded. For example, a lot of mappings have been made by the time the .gvimrc is sourced.

Sections

The .vimrc is split into the following top level sections using fold markers:

01	Windows, WSL specific options
02	Highlights
03	Settings (global)
04	Commands
05	Functions
06	Mappings
07	Autocommands
08	Plugins
09	Syntax + filetype
10	Cmdline completion
88	Deleted
98	Development

The .gvimrc is structured similarly.