The different approaches between `emacs` and `vim` packages
- 462 words
- 3 min
- tags:
- programming
- vim
- emacs
I recently tried using emacs
for the first time in many years (the last time I used emacs
was back in early 2017, and I moved to using vim
later that year).
Many of my colleagues at my last internship use emacs
- there was even an internal minor mode for editing and using many of the internal tools - and a number of friends at university are also emacs
evangelists, so I thought that it'd be a good idea to re-acquaint myself with the editor that I left behind.
Long story short - I've decided to stick with neovim
.
There's actually a bunch of reasons why (which I can probably go into at a later date), but my brief foray back into the world of emacs
showed me an interesting difference in philosophy between emacs
and vim
packages.
As someone who (of course) wants to use vim
bindings in every text editor that I use, I of course installed evil-mode
, the vim
compatibility layer for emacs
.
This went along quite swimmingly until I had to install other packages, all because they all automatically overrode keybinds.
This was a pattern that tended to find throughout my emacs
experience.
Packages create their own major or minor mode, and then provide a number of key-binds within that mode to interface with its functionality - which can cause a lot of problems for me when I've remapped a good number of the keys because I don't use a QWERTY keyboard.
It's become like a game for me. See how many plugins I can find that all try to override the same key-bind.
In my experience, vim
packages have the exact opposite approach - although I will fully admit to not using very many packages.
coc.nvim
, for example, doesn't set any keybinds and instead requires the user to assign their own binds to the functions that it provides.
FZF does exactly the same thing, as does vista.vim
.
This has actually been really surprising to me, as I would have likely expected the exact opposite.
I often hear emacs
talked about as being an "elisp interpreter with an editor attached" - which to me suggests that the primary focus of emacs
would be on elisp functions - whereas vim
's major selling point is its excellent keybindings.
I think that if emacs
packages had taken a similar approach to what vim
packages seem to - that I'd have expected them to take - then I'd almost certainly switch to emacs
for the additional flexibility of having the power of lisp at my fingertips.
As it is, however, it would take far too much work every time I install a package for me to want to move.