I'm now a user of Vim, not classical Vi (partly because of windows)

September 13, 2020

In the past I've written entries (such as this one) where I said that I was pretty much a Vi user, not really a Vim user, because I almost entirely stuck to Vi features. In a comment on my entry on not using and exploring Vim features, rjc reinforced this, saying that I seemed to be using vi instead of vim (and that there was nothing wrong with this). For a long time I thought this way myself, but these days this is not true any more. These days I really want Vim, not classical Vi.

The clear break point where I became a Vim user instead of a Vi user was when I started internalizing and heavily using Vim's (multi-)window commands (also). I started this as far back as 2016 (as signalled by this entry), but it took a while before I really had the window commands sink in and habits regarding them become routine (like using 'vi -o' on most occasions when I'm editing multiple files). I'm not completely fluid with Vim windows and I certainly haven't mastered all the commands, but at this point I definitely don't want to go back to not having them available.

(In my old vi days, editing multiple files was always a pain point where I would start reaching for another editor. I just really want to see more than one file on a screen at once in my usual editing style. Sometimes I want to see more than one spot in a file at the same time, too, especially when coding.)

I also very much want Vim's unlimited undo and redo, instead of a limited size undo. There are a bunch of reasons for this, but one of them is certainly that the Vi command set makes it rather easy to accidentally do a second edit operation as you're twitching around before you realize that you actually want to undo the first one. This is especially the case if your edit operation was an accident (where you hit the wrong keys by mistake or didn't realize that you weren't in insert mode), or if you've developed the habit of reflexively reflowing your current paragraph any time you pause in writing.

(There are probably other vim features I've become accustomed to without realizing it or without realizing that they're Vim features, not basic Vi features. Everywhere I use 'vi', it's really Vim.)

Although I'm now unapologetically using vim, my vimrc continues to be pretty minimal and is mostly dedicated to turning things off and setting sensible (ie modern) defaults, instead of old vi defaults. I'm unlikely to ever try to turn my vim into a superintelligent editor for reasons beyond the scope of this entry.

(I do use one Vim plugin in some of my vim setups, Aristotle Pagaltzis' vim-buftabline. I would probably be more enthused about it if I edited lots of files at once in my vim sessions, but usually I don't edit more than a couple at once.)


Comments on this page:

One of my pet peeves is that by default on a lot of Linux systems when you type in "vi" you actually get Vim. You can tell this is the case by the fact the file is colour/syntax-highlighted.

I'm sure this is a useful if you're writing code all day, but when you simply want to make a tweak to your .bashrc or my.cnf, then it's really distracting. If I wanted Vim I would have typed in "vim", thank you very much.

See also the default of having the output of "ls" colourized: thanks, but I have no idea what 'blue' means, especially in a multi-platform, heterogeneous environment. But I know, when running "ls -F", that a "/" at the end of an item means it's a directory.

A vim plugin you might look into is the Asynchronous Linter Engine (ALE). I code in a number of languages and ALE catches a number of silly style and syntax errors.

Used with things like shellcheck, pylint, go's lint tools, php checkers and so on, it's really handy at squashing a lot of the sillier errors.

By P Kern at 2020-09-17 12:19:15:

Thanks David Magda. I was afraid I might be the only "cranky old guy" still plugging away.

By rjc at 2020-09-20 17:28:37:

@David I couldn't agree more - first, well the second (after installing etckeeper), thing I do on Ubuntu is to install nvi and make sure the editor and vi alternatives point to it. The same goes for ex and view. By I, I obviously mean the config management systems ;^)

Fortunately, on OpenBSD I don't have to do anything as nvi is the default vi(1) :^)

Written on 13 September 2020.
« Rolling distribution releases versus periodic releases are a tradeoff
When the Go garbage collector will panic over bad pointer values »

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

Last modified: Sun Sep 13 23:51:47 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.