It is 2026, over 10 years after the neovim project forked from vim. For the first couple years of the project I didn’t think much of it; cool ideas, but ultimately something I thought would fizzle out and/or merge into the original project. Most people were using identical vimrc in vimscript, just named init.vim, and using the same plugins which have proved valuable for a long time - fedora tip to Tim Pope.

Around 2020 (from what I can remember) things started to change. Lua was becoming a first-class citizen in neovim, various projects which resembled Emacs distributions were popping up, lua plugins were becoming more popular and optimized, and other things to distinguish neovim from vim. Whilst I always tried to minimize the number of plugins I used in vim - mainly for speed since was/am using old laptops as GNU/Linux enjoyers are wont to do - in neovim it became increasingly irrelevent because of how snappy “bloated” lua configs could be. Neovim could easily become a full-blown terminal IDE without any effect on performance, making it loads faster than its IDE competition, and better by virtue of being vim vs a compatibility layer like in vscodium.

With that in mind, why do I continue to use paleo-vim?

Use case

Let’s first look at my vim use case. Professionally I am not a programmer (as much as I might cosplay with LISP at work). I use vim primarily for what it is: a text editor. I use vim to edit files on my desktop and the many servers that I use. I need to have a simple config that I can quickly copy over to a server when needed, or if not possible one that I can generate on my own. Vimrc in its default location (~/.vimrc) is quickest to transfer over to another server. Whilst this could easily be located in ~/.vim/vimrc, using scp this introduces a bit more complexity: removing the ~/.vimrc file if it exists, checking for the ~/.vim directory and creating it if not present, and then copying vimrc to the ~/.vim directory. Easy to script, but often I don’t want to hassle with that. The same logic applies for neovim just with ~/.config/init.vim. Many people make a big deal about crowding the home directory with dotfiles, and that’s something my tism really doesn’t care about. Perhaps more on that in another post.

Plugins

I have only a handful of plugins and each are lazy-loaded, meaning they don’t load until I call the plugin’s function. Currently [at this time] I am using vimwiki, vifm, and fzf. Generally I never use any of these plugins, and fzf comes in handly on occation when I’m looking for specific files for libraries in /var. I only use default colorschemes, and thanks to neovim-inspired updates there are some really good default colorschemes - retrobox gang rise up. My vimrc checks if the plugins directory exists before loading pluins - which is basically never on servers - so my vimrc is itempotent. Additionally I unfortunately use Windowns at work, so my vimrc has conditionals for Windowns and GNU/Linux/BSD. All this is possible on neovim of course, but it gets back to a more fundamental issue: why change an editor if nothing will change what I do with said editor?

Vimscript

I like vimscript. I use it all the time for ad-hoc commands within vim. Does it suck as a plugin language? Probably. Do I like lua? Yeah, I do like lua. It’s a smart choice for what neovim aims to achieve. I have used it in other programs. I don’t have strong feelings towards vim9script because I’ve never felt a need to deviate from paleo-vimscript. Hats off to neovim for keeping backwards compatibility with vimscript and also making compatability for vim9. Regardless of what you think of vimscript, you need to now some of it - at least ad-hoc set commands.

Gill Bates

Speaking of Windowns, I’ve found gvim works better than neovim. Despite vimrc having a different name in Windows (_vimrc), I have a macro that copies .vimrc and renames to _vimrc. Neovim on Windowns only works in the terminal, and short of alacritty the windows terminals aren’t great. I haven’t tried neovim on Windowns in about several years, so this has probably changed as a lot has happened with Neovim since.

Contrarian

As much as I try to fight it, I can be a contrarian. In 2026 using paleo-vim is the contrarian thing to do. When Bram passed (RIP) I wasn’t sure where the project would go, but fortunately it has been more or less business as usual since. This contrarian spirit extends to much of my computing setup: openrc, xorg / xlibre, Emacs, vanilla GNU/Emacs, C vs rust, etc, and in plenty of other areas in my life.

Emacs is Neovim but better

Rather than ricing out neovim to be an IDE, I prefer just using Emacs. I don’t buy in to the Emacs vs Vim wars because I use each to their strengths. I love the complete operating system Emacs provides and how it eliminates using terminal programs which have similarities, but ultimately are different beasts; they often have keybindings that conflict with one-another, or have some vim-like keybindings but not all of them. This is not a problem in Emacs, and even if it were it would be easy to rectify because of the major/minor mode structure. Weechat, newsboat, tmux, etc, are all wrapped into Emacs.

As a text editor and in the tty, vim absolutely reigns supreme, but Emacs with evil bindings is a passable vim. I have no issues opening a terminal and using vim if needed. But on all my servers vim is a must-have; I would never even think of installing Emacs on my alpine Linux servers just to edit text. More on Emacs in follow-up posts.

Separating Vim from Neovim

All that being said I have a lua-config of neovim on my system. I am a tinkerer and still enjoy the process of learning new things. I have nvchad installed and can open it with a specific config. I don’t regularly use these neovim flavours, but having them completely separate from my vim configs means I can fuxx around with neovim IDEs without touching my .vimrc or creating multiple inits which are called depending on what I want.

Love for the Neovim project

[Again] All that being said I think neovim has been a net-positive. It has completely changed that possibilities with vim, and the project itself has brought improvements to paleo-vim, e.g. improved default colorschemes as mentioned about. Regardless of how you feel about vim9script, it would not have happened had neovim never forked. Neovim has caused a splintering in the projects which I think is a good thing. Old crusty guys like myself stick to vim because of its simplicity and minimalism (relatively speaking; vim is actually bloat compared to nvi which is bloat compared to vi which is bloat compared to ed), and guys who want the plugin-heavy or IDE environment have moved away to a separate project.

This can keep the goals of each project consistent, and vim no longer has to cater to pull requests for features it deems appropriate for neovim. TJ and Prime and other neovim faces also seem like legitimately good guys, and in the past neovim devs have pushed their own improvements to vim when appropriate. Tons of users have discovered the goodness that is vim (in the broad sense) and have moved away from vscode, sublime, gedit (jk nobody uses that trash), or other IDEs/editors because of the hype neovim has on the internet. All good things and I think it shows the long-term (albeit seemingly rare) mutual success that can be possible from project forks.

Emacs is still better though.

Who else uses paleo-vim? Let me know.