I haven't customized my Vim setup and I'm not sure I should try to (yet)

June 2, 2019

I was recently reading At least one Vim trick you might not know (via). In passing, the article divides Vim users (and its tips) into purists, who deliberately use Vim with minimal configuration, and exobrains, who "stuff Vim full of plugins, functions, and homebrew mappings". All of this is to say that currently, as a Vim user I am a non-exobrain; I use Vim with minimal customization (although not none).

This is not because I am a deliberate purist. Instead, it's partly because I've so far perceived the universe of Vim customizations as a daunting and complex place that seems like too much work to explore when my Vim (in its current state) works well enough for me. Well, that's not entirely true. I'm also aware that I could improve my Vim experience with more knowledge and use of Vim's own built in features. Trying to add customizations to Vim when I haven't even mastered its relative basics doesn't seem like a smart idea, and it also seems like I'd make bad decisions about what to customize and how.

(Part of the dauntingness is that in my casual reading, there seem to be several different ways to manage and maintain Vim plugins. I don't know enough to pick the right one, or even evaluate which one is more popular or better.)

There are probably Vim customizations and plugins that could improve various aspects of my Vim experience. But finding them starts with the most difficult part, which is understanding what I actually want from my Vim experience and what sort of additions would clash with it. The way I've traditionally used Vim is that I treat it as a 'transparent' editor, one where my interest is in getting words (and sometimes code) down on the screen. In theory, a good change would be something that increases this transparency, that deals with some aspect of editing that currently breaks me out of the flow and makes me think about mechanics.

(I think that the most obvious candidate for this would be some sort of optional smart indentation for code and annoying things like YAML files. I don't want smart indentation all of the time, but putting the cursor in the right place by default is a great use of a computer, assuming that you can make it work well inside Vim's model.)

Of course the other advantage of mostly avoiding customizing my Vim experience is that it preserves a number of the advantages that make Vim a good sysadmin's editor. I edit files with Vim in a lot of different contexts, and it's useful if these all behave pretty much the same. And of course getting better at core Vim improves things for me in all of these environments, since core Vim is everywhere. Even if I someday start customizing my main personal Vim with extra things to make it nicer, focusing on core Vim until I think I have all of the basics I care about down is more generally useful right now.

(As an illustration of this, one little bit of core Vim that I've been finding more and more convenient as I remember it more is the Ctrl-A and Ctrl-X commands to increment and decrement numbers in the text. This is somewhat a peculiarity of our environment, but it comes up surprisingly often. And this works everywhere.)

PS: Emacs is not entirely simpler than Vim here as far as customization go, but I have a longer history with customizing Emacs than I do with Vim. And it does seem like Emacs has their package ecology fairly nailed down, based on my investigations from a while back for code editing.

Comments on this page:

By orev at 2019-06-02 13:30:46:

I have come to believe that the dividing line between vim customizers and purists comes down the Developer vs Sysadmin. If you have the luxury of always using the same environment (I.e. your own local workstation) such as what Developers do, then it makes sense to spend a bunch of time customizing to your specific workflow. However, as a Sysadmin one often has to login to many different machines, and spending time customizing all of them just doesn’t make any sense. (Dear DevOps purists, please spare us all the sanctimonious speeches about how one should never be editing files directly on severs, should only be using config management, etc. You just don’t live in the real world of Ops).

I lean to the purist side. There's a small handful of settings that I memorized, so I can write properly-indented Python anywhere, or whatever.

However, my personal system has gradually eroded its purism. Many parts of vim are configured slightly differently across distributions, so while I have memorized the commands to fix that, they're also part of my vimrc at home. I also started using a plugin manager, to provide little conveniences like ALE or endwise.

(FWIW, I switched from pathogen, literally the simplest thing that could possibly work, to VimPlug over time.)

By Jukka at 2019-06-03 10:45:32:

There is a grain of truth in orev's comment. Like with many things, however, I use multiple editors: one for system administration (KISS), one for coding (Emacs), occasionally another one for different kind of coding (IDE), and so forth.

Written on 02 June 2019.
« Some things on how ZFS dnode object IDs are allocated (which is not sequentially)
Exploring the start time of Prometheus alerts via ALERTS_FOR_STATE »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jun 2 00:23:58 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.