My .vimrc (and .gvimrc)

vim9script

I rebuilt my .vimrc and .gvimrc as vim9script 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 vimscript version handle all sorts of versions before vim9, all the way back to 7.x (which is now deprecated, though still handled in the _vimrc8 and _gvimrc8 files).

Structure

With vim9script allowing an initial vimscript section, the approach taken is to have the .vimrc only source _vimrc8 and _gvimrc8 (if using the GUI) when the version is before 8.2.3434.

If the version is 9 (or 8.2.3434 onwards, where vim9script works adequately) the .vimrc, or _vimrc, is used. Those files are identical. (Similarly, the .gvimrc or _gvimrc.) So, this is what happens:

Version and patch	Loads (all)	Loads (GUI)
gvim 900 or >=802 patch 3434	_vimrc	_gvimrc
gvim <802 patch 3434	_vimrc8 (sourced by _vimrc)	_gvimrc8 (sourced by _vimrc)
vim 900 or >=802 patch 3434	_vimrc
vim <802 patch 3434	_vimrc8 (sourced by _vimrc)

Note	To repeat, .vimrc and .gvimrc are clones of vimrc and _gvimrc respectively. They may be used by Linux, WSL, etc., but it’s just as straightforward to make a symbolic link to the versions, which has the added advantage of showing up with a normal ls or ls -l.

There are only a few things in the vim9script _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 v:versionlong conditional test. An example is the option cdhome, which was not available until version 8.2 with patch 3780:

if v:versionlong >= 8023780
  set cdhome
endif

Linux

If the GUI is not needed, using .vimrc and .vimrc8 (if necessary) directly in the $HOME directory is the simplest approach.

Alternatively, Vim will read a .vimrc symbolic link, so another means to ensure a clean local repository is to have a ~/vimrc folder (i.e., in the same location as the .vimrc used by Vim). That also allows for a clean cloned git repository and for easy updating back to github. If the GUI is used, similarly, have a symbolic link to ~/vimrc folder and have the .gvimrc in there too.

Windows

The _vimrc is a clone of the .vimrc; there is nothing in either that is incompatible with the other operating system. That is, everything should work in Windows and Linux (or WSL) and vice versa.

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

GUI

The GUI is applicable to both operating systems. From 2023-07-15, I separated most of the GUI-specific things into a .gvimrc / _gvimrc - this was driven by making a specific Toolbar for gvim. It is also the recommended way of keeping GUI-related settings distinct. This has grown a bit but it is still nowhere near as large as the .vimrc, which makes sense.

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 vim90 folder .vim files (e.g., syntax.vim)

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

• Other vim90 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 / _vimrc is split into sections:

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

The .gvimrc / _gvimrc are similarly structured.