Hacker News Reader

Comment by copperx | Hacker News Reader

Vim is attractive to many because it launches in a fraction of a second. This is especially important to sysadmins, who don't "live in a text editor." It's also quite popular to use vim without customization.

I understand that some people have simple needs. I don't. The editor wars are over for me and Emacs has won.

View on HN

Startup time is a non-issue for both Vim and GNU Emacs on modern hardware. (It was not ever so: I remember first meeting Emacs under DOS on a 20MHz 386. It was not speedy.)

Perhaps another underrated issue affecting relative uptake is keyboard layout.

As the OP explained, Berkeley vi was originally developed on an ADM-3A tty, with no arrow keys and the "Esc" key where a modern keyboard would position the "Tab" key.

In contrast, Emacs first appeared in anything like its modern form on LISP machines, which had a radically different keyboard layout from a modern PC or Mac — much less austere, lots of modifier keys (not just Ctrl and Alt, but Meta, Super, and Hyper as well!), and an Esc key tucked out of the way at the top left, as is standard today. Here's s photo: https://upload.wikimedia.org/wikipedia/commons/9/9a/Symbolic...

If you consider the ergonomics of typing lots of Ctrl- and Meta- keystrokes on the Symbolics keyboard above, it's fairly clear that it requires a lot less hand stretching to play those chords in the key of Emacs. So it was a cheap design choice for the original Emacs folks to take that route — but every time I've tried to spend serious time in Emacs over the past 30 years on a PC or Mac keyboard, I've ended up with stabbing pains in my wrists within a week (and I will note that back in the 1990s FSF programmers were notorious for always wearing wrist splints).

The basic vi commands can all be executed from the main QWERTY keyboard area, plus the Enter, Ctrl, and Esc keys. If the position of Esc really bugs you, you can rebind it to the Caps Lock key on your keyboard (depending on hardware support, of course). The point is, there's far less chording involved.

So my working hypothesis is that vim is gaining leverage due to selection bias for an editor that hurts the hands less when you use it intensively on an IBM PC-descended keyboard layout rather than a Symbolics keyboard. But "less pain in wrists" is not something we spot easily, so a whole load of post-hoc justifications get invoked to explain the preference.

Nit: "not ever" and "never" are synonymous. I think you meant "it was ever so" or "it was always so" or "it was not ever an issue".

Interesting hypothesis. Ergonomics is certainly one of the reasons I chose vim over emacs.

Your equation of "not ever" and "never" is off - "ever" means "always", and "never" means "always not" ("ever not"). In logic terms:

"Ever so" = for all, so

"Never so" = for all, not so

"Not ever so" = not (for all, so) = there exists, where not so.

The last is fairly clearly the intent of GP. Startup is short either way now, but there exists a time when it was not short - insert references to old slow hardware that would take 10-20 seconds to boot emacs.

> every time I've tried to spend serious time in Emacs over the past 30 years on a PC or Mac keyboard, I've ended up with stabbing pains in my wrists within a week

I used to think "emacs pinky" was a joke, but it is real. Eventually I learned how to re-map Caps Lock to be a Ctrl-key (I never used Caps Lock anyway), and Caps Lock is far more comfortable to reach with my pinky than either of the regular Ctrl-keys.

Yup. Remapping Caps Lock is kind of a shibboleth for Vim/Emacs users. Emacs users remap to CTRL; I hear Vim users remap to ESC.

Vim users do indeed. I still get a bit of ESC pinky, but not nearly as bad as the default layout would cause.

Wouldn't you hit ESC with your ring finger or middle finger instead? (When I used vim, I preferred Ctrl-C so I would not have to move my fingers so far.)

That would require lifting my hand off the home row, which would be uncomfortable on my wrists. Playing around with it now, the motion seems to be more of a sideswipe, with a bit of muscle tone to keep the finger from just bending out of the way.

Side note - I've noticed a big improvement in general hand pain since I got into climbing regularly, and specifically starting working with a hand exerciser.

I sometimes wonder who came up with the idea for Caps Lock anyway. I cannot remember ever using that key except by accident.

Because you got me curious enough to look this up:

It apparently originates from typewriters, when holding shift was quite physically taxing (since it literally shifted all the typeheads over to put alternate characters over the ribbon); so caps lock saved a lot of finger strain when typing acronyms or writing symbol-heavy text.

Thank you! It is kind of fascinating how much legacy from the typewriter era modern keyboard carry with them.

I like mapping jk to ESC for vim/evil-mode, then swapping caps lock and CTRL for the comfy tmux and readline ergonomics. (I've tried readline's vi mode, but I didn't like it.)

Emacs is sufficiently powerful that I think it’s worthwhile to use a keyboard with a proper set of modifiers. Moreover, the emacs approach is sufficiently powerful that I think it's worthwhile to use a keyboard with a proper set of modifiers in any program. Use easily-hit keychords for common functions and more-difficultly-hit chords for uncommon ones; maybe even reserve a prefix for certain uses (e.g. Super for the OS & Hyper for the user).

It's 2018; our keyboards could stand to keep up.

Not just its launch time but its ubiquity, vi comes installed on pretty much every linux/unix machine no matter how minimal the install so if you are a sysadmin whose job involves jumping between machines a lot it makes far more sense to learn vi then install emacs everywhere. Its also the reason to use it without customization so you dont come to rely on a feature that isn't installed on that one machine with a critical problem

Developers tend to work on a single machine so can tailor it much more to their own preferences.

OTOH, emacs has TRAMP which allows you to edit files remotely, using ftp or ssh as the transport layer. (Okay, I do not use that feature often, and I do still use vi sometimes for quickly editing a config file or something).

vim comes bundled with netrw, which lets you do the same thing.

A normal sysadmin workflow would be, log in via ssh, poke at some log files, run a couple of commands, edit a config file, restart a service, check the logs again, logout. If you need to be ssh'd in anyway to run commands then being able to edit a file remotely is of limited value.

I actually really like emacs, for a while I used it as my login shell (no x-windows and with e-shell providing a command line), and elisp is an awesome tool (in theory if not always in practice), but when I moved into sysadmining and later consulting the practical issues meant vi was by far the best option.

> If you need to be ssh'd in anyway to run commands then being able to edit a file remotely is of limited value.

You can access the remote shell from TRAMP and run commands, just like you can access the local shell from Emacs on your local machine.

Like I said, I don't use TRAMP very often.

The number of Unixoid systems I have to take care of is sufficiently small that installing emacs on all of them is no big deal. I usually start an emacs daemon after booting and use emacsclient to fire up an editor, which is almost instantaneously.

> A normal sysadmin workflow would be, log in via ssh, poke at some log files, run a couple of commands, edit a config file, restart a service, check the logs again, logout. If you need to be ssh'd in anyway to run commands then being able to edit a file remotely is of limited value.

eshell supports TRAMP: from an eshell, you can do something like 'cd /ssh:news@news.my.domain:/opt/news/etc' and then run `ls` &c., seeing the results you expect. You can run 'service restart innd' or whatever you'd like, it it runs remotely.

Yeah, emacs is pretty awesome.

That's true. In the eternal Vim vs. Emacs discussion, I found that preference is correlated to whether a particular person feels more like a ops/sysadmin, or more like a programmer. As you wrote, developers tend to work on a single machine, while sysadmins tend to jump between many machines.

I'm a developer, not a sysadmin, though I try to do most of my ops work via Tramp these days. I wish an actual sysadmin and Emacs user could chime in and say something about their workflow, and the problems they encounter.

The performance issue isn't about sysadmins wanting fraction-of-a-second launches; it's about Serious Programmers back in the 90s wanting precious memory. "Eight Megs And Constantly Swapping" was the derogatory nickname, back when eight megs was a lot.

(And, secondarily, launch times then were longer; 0.2 seconds vim vs. 2 seconds emacs is a very different comparison than between 2-second vim and 20-second emacs.)

I want my software to be instant, or as close to it as feasible. Vim is fast enough, make sometimes, and gcc not. This is in syntax-only mode for the latter.

But how can you get more instant than "it's already running"? The emacs way of doing things seems to be to do _everything_ in emacs -- it's your shell, your editor, your debugger, your mail client. Vim users, on the other hand, tend to only open vim when they need it.

> Vim is attractive to many because it launches in a fraction of a second

I often joke than with all the Vim plugins I use, I manage to make my Vim starts as slowly as Emacs (I haven't encountered wide popular success with this joke though)

Reply on news.ycombinator.com