"I was reading about vim the other day and found out why it used hjkl keys as arrow keys. When Bill Joy created the vi text editor he used the ADM-3A terminal, which had the arrows on hjkl keys, so naturally he reused the same keys." As interesting as that is, John Graham-Cumming goes even further back in history. "The reason that keyboard had those arrows keys on it was because those keys correspond to CTRL-H, J, K, L and the CTRL key back then worked by killing bit 6 (and bit 5) of the characters being typed." Truly fascinating stuff, even though it's from way before my time (I'm from 1984).

A lot of old keyboards had linear arrow keys, including the first IBM PC and the Symbolics Lisp Machines. The inverted T only started appearing in the early eighties (and there are even +-shaped arrow key layouts for special terminals, usually with 'Return' or something similar in the middle.)

I've checked. You're right. I must have confused myself. But I've seen that difference in behaviour in some other editor. Maybe it was Vi, maybe it was Vim on console mode, maybe it was Emacs... who knows.

So Vim is an example of out dated hardware model enforced in the new one? Good job.

So "Windows" and most of today's programs are also an example of something outdated enforced on the users?

Remember:

Ctrl-Z = undo
Ctrl-X = cut
Ctrl-C = copy
Ctrl-V = paste

See where Z, X, C and V are located on your keyboard (or refer to the US keyboard layout if needed). Looks obvious? You can do some research (simple web search should be sufficient) why this is, and why it still exists today.

To come back why it's actually a good thing to have something "outdated" in vim (and in vi, too): Imagine you have to connect to a UNIX system (or Linux, Solaris, HP-UX or AIX, whatever) that just functions in a minimal state and needs maintenance. The responsible sysadmin has made a mistake and terminal capabilitites don't work at the "high level" you expect, which is required to use the arrow keys. Still you can connect to that system and need to edit a file in the "visual editor" (vi). Whenever you press a cursor key, garbage appears in your terminal session, but the desired cursor movement doesn't happen. But using the HJKL keys will - together with the other "letters only" command keys of vi - to get your job done. In worst case, this is what you want.

But wait, there's more:

Imagine a person with impaired movement of the arm (arm in singular may mean that only one arm is available) or the hand uses a computer. Compare the travelling distance of the fingers from the alphanumeric keyboard section over to the cursor keys. Know that the Escape key is used to switch vi's modes. Now you can easily recognize that having the alternative not to use the cursor keys can be a benefit!

Of course, all those considerations don't apply to mouse-driven users, just as vi doesn't apply to any average person. :-)

"Imagine a person with impaired movement of the arm (arm in singular may mean that only one arm is available) or the hand uses a computer. Compare the travelling distance of the fingers from the alphanumeric keyboard section over to the cursor keys. Know that the Escape key is used to switch vi's modes. Now you can easily recognize that having the alternative not to use the cursor keys can be a benefit!"

Personally, I have mixed feelings about VI. I do use it all the time simply because it's available everywhere and that makes it an essential tool. But VI's modes often get in the way of what my brain is thinking and I'd much rather use a stateless interface so my poor escape key can get some rest. To be honest I find ESC to be even less "accessible" than arrow keys are, and while the arrow keys are supported these days, dropping to command mode is still a frequent requirement. Raise your hands, how many people accidentally type or paste text into command mode? I prefer stateless hotkeys because pressing and releasing a modifier has no side effects and I don't have to concentrate on what mode my editor is in (ALT changes focus to menu bar on windows, but CTRL is stateless). I do appreciate the technical limitations under which VI evolved, and I will continue to use it on the console simply out of habit.

Personally, I have mixed feelings about VI. I do use it all the time simply because it's available everywhere and that makes it an essential tool.

Similar here: I can use when I have to use it, but I prefer a different editor for "normal" use (stateless, as you continue to explain).

To be honest I find ESC to be even less "accessible" than arrow keys are, [...]

Compare its position on "historical" keyboards. The escape key typically has been located on the left, near the number keys (above the Tab key). This changed when the PC became modern (see transition of XT to AT to MF2 keyboard layout).

[...] and while the arrow keys are supported these days, dropping to command mode is still a frequent requirement.

In vi, yes. Many of its "power user functions" are addressed by that mode, whereas the "usual functions" are to be controlled directly.

I prefer stateless hotkeys because pressing and releasing a modifier has no side effects and I don't have to concentrate on what mode my editor is in (ALT changes focus to menu bar on windows, but CTRL is stateless).

I agree. Let me look back when I did use TP (a WordStar-inspired text processing program used on the SCP and DCP operating systems). Control plus one or two letters was the standard way of accessing program functions. Later on, I discovered the editor "joe" and found that it also uses that interface. Together with a good visual representation, this approach is very powerful and grants access to "power user functions". An example: You mark a block with ^KB (block begin) and ^KK (block end), and you can move the block margins intependently, you can even change the block's content while the selection is active (those things are usually impossible in "modern" mouse-driven editors). ^KC copies, ^KM moves and ^KY deletes the block.

But also the editor of the Midnight Commander ("mcedit") focuses on good keyboard support. It uses the programmable function keys which need some "travel distance" for the hands, but can be quickly accessed without visual confirmation. An example regarding blocks: PF3 marks beginning and end of block, PF5 copies, PF6 moves and PF8 deletes it, such as PF5 copies, PF6 moves and PF8 deletes files in the "parent" application. Note that this editor can be used as a stand-alone program, but is known for its excellent integration with the MC.

However, pasting command sequences into the command mode is something that you cannot easily achieve with editors that use hotkeys to address program functions. How would you copy a sequence of key combinations? You need to manually re-type them.

I do appreciate the technical limitations under which VI evolved, and I will continue to use it on the console simply out of habit.

The initial article educated us about why vi initially used HJKL for cursor control. The ability to still use them can be a benefit in "niche situations", but for today's considerations of use, they have (nearly) no meaning than their historical reasons.

Stateful and stateless editors both have their benefits. Use them together. Use them in peace. :-)

To be honest I find ESC to be even less "accessible" than arrow keys are

I'm not sure about your keyboard, but I can easily press ESC+F on Apple (and pc laptop) keyboards , but can't reach cursor keys without moving a hand.
Also arrow keys on laptop keyboard are too small to be usable.

Personally, I have mixed feelings about VI. I do use it all the time simply because it's available everywhere and that makes it an essential tool. But VI's modes often get in the way of what my brain is thinking and I'd much rather use a stateless interface so my poor escape key can get some rest.

IIRC, VIM has an easy mode, something like -E option.

To be honest I find ESC to be even less "accessible" than arrow keys are

See where Z, X, C and V are located on your keyboard (or refer to the US keyboard layout if needed). Looks obvious? You can do some research (simple web search should be sufficient) why this is, and why it still exists today.

Born with an AZERTY keyboard in the hand, I always figured that it was because it makes sense from a usability point of view to have cut, copy, and paste close to each other.

It's true that if you add cancel to the mix, it starts to feel like a software performance hack.

Imagine a person with impaired movement of the arm (arm in singular may mean that only one arm is available) or the hand uses a computer. Compare the travelling distance of the fingers from the alphanumeric keyboard section over to the cursor keys. Know that the Escape key is used to switch vi's modes. Now you can easily recognize that having the alternative not to use the cursor keys can be a benefit!

"A minimum for remote access" or... touchtyping are all well and good, but this^ one might be not so simple, & perhaps you should have looked at the keyboard while typing it. :p

HJKL are basically right in the middle between Esc and cursor keys (for somebody who certainly doesn't type that much in the first place, home row resting place has less meaning) ...plus:

a) cursor keys are typically quite conveniently at least as a semi-separate block, most importantly with no keys below them that can be hit accidentally

b) HJKL & Esc require attention to not hit any of the keys around and below, by that malfunctioning hand.

So as to which one's easier ...yeah, I remember well how it worked when I had my broken hand in a plaster - cursor keys were one of the few totally unaffected, usage-wise (modal things were the biggest issue)

Of course, all those considerations don't apply to mouse-driven users, just as vi doesn't apply to any average person. :-)

Though OTOH even vi (and such) users still fall under http://plan9.bell-labs.com/wiki/plan9/Mouse_vs._keyboard/index.html ...their brains aren't that "non-average" (generally, being very invested into this stuff makes some biases of perception easier - remember, they are felt by the very same organ which invested a lot of effort into given skill)

I'll go a step further and claim that the ASCII control codes explanation just doesn't cut it.

Think of it this way: these control codes are grouped, ASCII goes in alphabetical order, and QWERTY keyboards are not in alphabetical order. That leaves two options: ASCII was designed with this function in mind, or we have a bit of a coincidence on our hands. There are only two groups of letters that follow this linear pattern after all (hjkl, and dfgh) and many other scenarios where the movement keys would have been mapped all over the keyboard.

I believe that the non-printing control codes (C0 codes) have a history dating back to the 1870's. First with the Baudot Code (circa 1870), to the Murray Code (circa 1900), to ITA-2 (circa 1930), to ASCII and ANSI variants now used. These were established for use with teleprinters to replace telegraph/Morse Code type transmissions.

So I would have to agree that this h-j-k-l layout of CO codes was indeed a intentional design. A "teletype" kind of functionality built into early dumb terminals and coded into vi and inherited by vim.

It's one of those things that's an acquired taste I reckon. I like it personally, I also like plenty of text editors that are more obvious when it comes to exposing functionality. Never the less, vim is a powerful text editor and when it comes to a cli editor being used over a remote shell it's hard to beat. After using it for a while it almost becomes second nature, you do things without even thinking anything more than "I want to do this..." and it happens. Like a motor skill almost.

I use currently use vim-tiny which on Debian and Ubuntu seems to be the 'default' vi-version right now.

My guess is because the old default which I used before that, nvi, doesn't support Unicode.

I do system administration and any time a server is really busy I just want a small editor start will actually start up in a reasonable amount of time, instead of vim ( which feels to much like emacs in size ;-) )

So in a roundabout way I want to say I'm a vim user too and it is my preferred editor on the commandline and the commandline is what is I prefer over the GUI.

It's one of those things that's an acquired taste I reckon. [...] After using it for a while it almost becomes second nature, you do things without even thinking anything more than "I want to do this..." and it happens. Like a motor skill almost.

Moreover, it's not only how we feel keyboarding around to be faster - remember what is responsible for that feeling: the very same organ which expedited a lot of effort into it (& go through a list of cognitive biases)

It's not really about features, although vim has accrued many since it's forefather vi came to life as a horribly bloated ed. It's about efficiency of operation that results from the old school UNIX terseness. Once you get past the initial pain and learn to properly operate it you really start to appreciate the design.

Once you get past the initial pain and learn to properly operate it you really start to appreciate the design.

That's also one of our cognitive biases, we value things we invested a lot of time in (even no matter if they make sense and so on; or at least, here, influenced by http://www.osnews.com/permalink?510905 )

I believe that nowadays you can easily find an editor that matches vim in feature wise but the elegance of vim is that it works perfectly over 9600 baud modem The bandwith of sending over couple of one-char commands does not kill the modem.

the elegance of vim is that it works perfectly over 9600 baud modem The bandwith of sending over couple of one-char commands does not kill the modem.

'telnet/ssh into the server and edit with vim' used to be a good idea when connections had low bandwidth but were otherwise fairly reliable.

Nowadays, it seems to me bandwidth is not much of an issue anymore, and the problem is unpredictable latencies, especially on mobile/wireless networks. The model of 'fetch the complete document, edit it locally, and sync it back' seems to fit that context much better.

Would be curious to see some sort of feature matrix comparing it with the best open source and commercial text editors out there.

Let me tell me "how I started using vim" (including this post via ViewSourceWith firefox extension).
Back in, 2001, I started playing around with Windows XP beta that I got from my MSDN account.
Back at the time, I was a low-level Win32 programmer that used MSDev 2K for-more-or-less everything.
Long story short, didn't like XP, decided I needed a switch and given that fact that I always had some type of Linux running on some old hardware, I decided to give it a shot.
Started looking for editors, kate, gedit, kdevelop, anjuta, tried them all and at the time (again, 11 years ago) non of them came even close to matching MSDev.
A friend, offered me to try vim.
At first, I hated it.
Then, I got used to it.
Now, well, now-days, when I'm forced to use Windows, the first thing that I install is Firefox (w/ the Pentadactyl vim interface and ViewSourceWith) and gvim.
The irony is that these days I can't stand using MSDev anymore, compared to gvim, it's SLOW, everything requires far too many mouse clicks and menus and the lack of "command mode" drives me crazy (I know that there are vim-for-VS plugins).
In vim, my mouse is rarely used; I can use regular expression more-or-less everywhere and everything; cscope is by an order of magnitude faster than anything eclipse and VS is using for tag matching (keep in mind that my cscope DB includes /usr/include, the full kernel source and both MinGW Win32 and Win64, all-in-all around 600MB of symbols).

Never the less, as others pointed out, it's really a matter of personal preference.

I can't stand IDE's. To slow, to much memory. Usually leads to terrible code with some of the tooling. No idea why people use them.

We use them because of the tooling they offer. I am an old time Emacs user, and I also know my way around VI, as in many companies it is the only UNIX editor available.

But in my workstation nothing beats the code navigation tools with compilation in the background and automatic code completion that the IDE offers (ctags is a joke), plus the integration with workflow tools usually used in enterprise context.

"Vim is absolutely the best text editor out there! I use it always, for everything and anything

Is it really? I've heard this said before, but I've never tried it myself... always seemed to be a bit of a pain in the ass to use.

Would be curious to see some sort of feature matrix comparing it with the best open source and commercial text editors out there. "

VIM is vi on steroids, so yeah, it does more than "classic" vi. But people like classic vi more for the brevity of keys, which makes it easier to touchtype. The commands interact very well, so finding / replacing / deleting / reformatting is fairly easy, moreso than other common text editors. But the brevity means you have to remember a lot of stuff. However, VIM mitigates most of that with its :help and menus, etc. (VILE is also a good one.)

27 comments about vi and nobody brings up Emacs?
What happened to the old war? Is that over now?
Has vi won?

Several years ago, it was said that O'Reilly sold 2x more books about vi than Emacs. And isn't vi in POSIX / OpenGroup / whatever nowadays? And Emacs has VIPER. And news://comp.editors is always about VIM, 10x more than anything else. So yeah, vi "kinda" won, though obviously Emacs is good too (and beats "classic" vi in raw features any day).

emacs is a fantastic OS, full of features both useful and occasionally baffling. vi however is the only text editor you can almost 100% rely on being installed on a *nix machine (looking at you Gentoo) so you sorta need to know the basics no matter what if you're even slightly serious about being a *nix admin.

(note: offtopic to some extent) Well, I'm only 5 years older, but I knew that Funny thing - or not so, sometimes it's hard to decide - when such topics come up and sometimes make me feel really old. Or when people make funny faces when it turns out I still know all the alt-keycodes for a lot of special characters and foreign accented characters. And I could go just go on with other examples. Whatever, the post's info is still interesting so it's good it's being brought up from time to time