Emacs, Vim, and Me

[Written July 13, 2023; updated August 13, 2023]

I tried Emacs once, and I hated it.  There were so many control/meta combinations and sequences.  Worst case, something would be available on M-x butterfly and I did not know about tab completion yet, nor did I want to memorize and type function names.  The Home/End keys did unexpected things, because (it turned out) a basic “pc keys” setting wasn’t active by default.

I learned vim instead.  It was a bit painful getting used to modes (learning not to start typing text in Normal mode), but multi-level undo helped, and having so many movement commands available without weird contortions was pleasant.

At the time, those were the only apparent choices; if I’d known of nano, I would have thought that (like pico) it too simplistic for the task of “real” programming.  I was on the hunt for a terminal editor specifically, not an X11-only editor, because I thought the terminal was cool.  That worked out great for editing over SSH as well, but I didn’t know that yet.

Years later, an Emacs user would be appalled, and tried to get an Emacs setup for me.  The main problem was that his environment was so customized, he couldn’t do a lot for me from scratch.  He had to reference his own ~/.emacs to find out what he had installed and how it was configured.

Seeing this, I wondered how I was supposed to keep an Emacs setup in sync between work machines at the office, and personal machines at home.  These were obviously air-gapped, and the office did not necessarily want random USB sticks being plugged in.

And in the end, it would still be Emacs.  However more “advanced” having an inferior mode integrated into the editor was, it would be a massive investment.  The attempt at using VIPER (hey, if “Emacs is an OS, ha ha,” then it should not be so hard to implement vim, right?) ran aground quickly: the mental vi/vim split I had maintained in college (some machines had nvi) was gone, and I used so many vim features that VIPER did not support.  Visual mode especially.

For its part, vim came with pretty reasonable defaults, and needed a single :set line to make it ‘more habitable,’ if the defaults didn’t suffice.  Perhaps also :syntax on; I had started with Vim 5’s syntax highlighting, and quickly found it difficult to read code without highlights.  On the other side, it was pretty clear I was never going to memorize a whole .emacs.d tree, and maybe not even diffs of it.

Had spacemacs🌎 been around a decade or so earlier… maybe?  But probably not. It would still be Emacs, after all.

The only thing that was able to break the power of vim was PHPStorm.  “Jump to definition” and “find usages” were becoming increasingly useful on growing code bases, and back on the Vim side, LSP support was still in its infancy. Even if I could have set up Vim with LSP, the alternative worked out-of-the-box, and came with professional/commercial maintenance and support. Oh yeah, and XDebug actually worked (unlike Eclipse/NetBeans.)

I’m sure Emacs users are appalled.

P.S. I never bothered with a vi keymap for PHPStorm.  VIPER had disappointed me, of course.  VS Code’s vim plugin, at the time I wanted to use it, hadn’t added support for text objects yet, so that didn’t work great, either.  (I had not rested; I had continued deepening my vim knowledge.)  I decided the proper way to approach PHPStorm was to learn the keybindings as they were, and hope that its more advanced commands would compensate for the limited fine-grained motions.  This has worked out pretty well.

Revision History