To understand the command line...
geekblog.oneandoneis2.org
geekblog.oneandoneis2.org
Something else that had long-lasting influence over software we still use today was the ADM-3A terminal. If you ever wondered why vi uses 'hjkl' as left,down,up,right - this is why.
You won't find anyone who believes more strongly than I do in the importance of understanding our history. But understanding history is different than making a fetish of it, and this explanation tiptoes pretty close to the latter. OK, vi uses hjkl because the ADM-3A terminal didn't have arrow keys. But every keyboard for decades now has had arrow keys. Given that, what's the value in pretending they do not?
This explanation basically boils down to "we do it that way because we've always done it that way," which is poor argumentation.
It's also a good illustration of the distinction between 'easy' and 'efficient' - the modern cursor key layout, with the 'up' in front of the 'down', is obvious, intuitive, and easy to master. No argument. But it's not the most efficient layout - it's not possible to keep all four fingers on the four navigation keys - you have to settle for three fingers and move them around. And if you're typing and suddenly need to move, you have to move completely away from where you're typing and switch to the cursors.
hjkl answers both issues - the four keys in a line make it possible to keep one finger on each and so move about as quickly as possible, without ever having to move from the text-entry part of the keyboard to any other. It's not as easy, not as obvious, but it's quicker and more efficient when you're used to it. Even on my modern keyboard, I go for hjkl far more than I reach for cursors.
Well sure you do, because you have trained yourself to do that. But how many people can say that? And what's the value in leaving everybody else out when you design your tools?
Anytime you talk about how UNIX-like systems have evolved, there's a danger of falling into the trap of hailing historical cruft as "misunderstood features." But at the end of the day, it's still just historical cruft. It's there, it won't kill anyone if it stays there, but it's not something awesome either. It's just an evolutionary dead-end; the male nipple of software design.
Put this in your .vimrc or just try it out from the command bar:
inoremap jj <Esc>
If you introduce new users to vi on a keyboard that supports arrow navigation in insert mode, they're likely to build a habit of navigating around in insert mode, a very bad habit to have.
Transactional interaction is fundamental to becoming adept with vi. Modal editing is such a good thing that vi has remained part of the unix canon, despite all of the things that are wrong with it (not least of all - unintuitive arrows).
It's unfortunate that there's no block of unused letters in the vi keylayout - nowhere to put an asdw directional layout with harming key functions.
Why?
This is the line of thinking that I was intending to challenge.
A wise man once said to me -- if the user and the software don't fit together elegantly, there's only two ways you can respond: by fixing the software, or fixing the user. In nearly every case, fixing the software to work the way the user expects is easier and cheaper than trying to fix every user who ever encounters it to work the way the program wants them to.
Steering users away from arrows is trying to fix the user. It's pushing her away from what every other bit of software on her system, including the OS itself, has trained her to do, to a different pattern that this one program believes is better.
For this demographic, HJKL is just wrong.
Computer gamers are also proficient in controlling a keyboard and a mouse at the same time, so the home row argument does not apply.
j still moves you in the same direction as ctrl-j (linefeed)
h still moves you in the same direction as ctrl-h (backspace)
there's never been a good association between k or l and their ctrled equivalents; no gain or loss there
u is now up - mnemonic ftw
moving undo to ctrl-u would make redo (ctrl-r) more discoverable
Of course, already having muscle memory for hjkl from vim, robots, hack, &c, I'm not rebinding anything standard - I find it valuable to be sufficiently at home on any system I am I find myself working on.
About those keys - with the possible exception of S - all those keys are tied to significant functionality you wouldn't want to replace.
Gamers are proficient in their niche; game playing. However if the job is to hammer out 400 lines of code or a manual, I'd back an expert touch-typist proficient with Vim over a gamer every time.
It's difficult to explain; the kind of people I'm talking about are experts in not just typing; they are super-proficient in coding as well. They have the text in their head, they just want to feed it to the computer in the shortest time possible. I've sat and watched an Unix guru create a program from scratch with Vi - it's a marvel, it's quite like watching an expert race car driver, if you're into that sort of thing.
Still, I think there's some sense in being able to control your editor without moving your fingers from the home row, and learning unintuitive-but-powerful tools for a significant subset of users. If you spend eight hours a day most days using a text editor, then criteria like [ease-of-use to new-comers] ranks a lot lower than others, such as sheer power.
Regarding user expectations - the OS doesn't train users to use the arrows. Bash does, and only when it's in emacs mode. If you sat down at a Solaris console, often ksh would be the default prompt and arrows wouldn't work. Vi interaction would. (You can configure bash to work like this - this is how I work. set -o vi)
I realise that from the perspective of a new user, what I've said above that would feel like an insultingly meaningless technicality. That kind of thing used to drive me around the bend.
I strongly agree with your conclusion,
Anytime you talk about how UNIX-like systems have
evolved, there's a danger of falling into the trap of
hailing historical cruft as "misunderstood features."
But at the end of the day, it's still just historical
cruft.
But that's not true if you're the kind of user that uses VIM regularly, since many CLI (ncurses) programs use the same keys. And even on the web: Gmail, Google Reader, Google+, Reddit, Jira, Tumblr, Tiny Tiny RSS and others support J/K for up/down navigation.
Anyway, adding keyboard navigation directly to a web app (instead of as a browser extension) breaks the "do one thing and do it well" philosophy.
This is why Google Chrome doesn't allow one to use Backspace to go back to the previous page (the most used shortcut for a browser) or Slash to trigger inline search. Instead, you have to use CTRL-Left and CTRL-F, as the one-key shortcuts are reserved for their web apps.
/usr/games/robots
I do have an inefficiency: I move my hand for the escape key (which I should remap to caps lock, but I've never gotten around to it in the past decade), but I pivot at the elbow. It's far less awkward.
inoremap jj <Esc>
In insert mode you just press j twice and you get out of insert mode. This is my favorite key remap in vim.
You can put that in your .vimrc file or just try it out from the command bar.
I'm not sure why, but I found it to be more fluid for me?
Same solution here. This favors people who tend to move from top to bottom during skimming a piece of code utilizing the j-key to move further down, which then let's you automagically exit EDIT-mode. Happens to me every fourth/fifth time.
Earlier it was more often. However, as skills develop I increasingly rarely use the hjkl-keys.
These days vim is placed at the end of a git/grep toolchain and most likely I tend to "/\v" for something or move more like "45j" directly to the place in focus (relativenumbers are your friend). Being in a row the natural tendency now is to jump with "f" or "F" and repeating with ";" if necessary.
If you passed this milestone already, your opinion is highly welcome!
larger moves are a mix of the {}() and /\v if I know what I am looking for by name. c-f c-b is nice if I am just browsing the code.
Ctrl-[
The only downside is being confused when nothing happens in a browser...
The only downside is being confused when
https://github.com/alols/xcape
now capslock does both ctrl and escape
best settings ever!
I've dealt with this by switching ctrl and alt - I find hitting alt with my thumb is far less strenuous than reaching for ctrl with my pinky.
I may give xcape a shot, however.
Now, I could dmap ctrl-l to esc. But I'm so used to the high-left pivot for 'esc' on Thinkpad keypads (and it's a tall key making for an easier target) that it's not worth the bother.
I disagree. I started out using the cursor keys all the time because they were what I was used to.
It wasn't until I had been using vim for hours every day for well over a year that I came to slowly prefer hjkl - it's not a habit from "the old days"; it's not leftover cruft we'd be better off without; it genuinely is better to use hjkl than the cursor keys.
If you do enough editing to make it worthwhile to build up the muscle memory, that is.
Having said that, I remapped the "up" and "down" cursor keys and I've started using them a lot more since:
noremap <Up> gk noremap <Down> gj
They now allow me to navigate up & down wrapped lines the more intuitive way of one keypress per visible line, rather than the still-useful vim way of one keypress per actual line.
YMMV.
-- The author :)
1. I didn't get the feeling that the author was claiming (here) that hjkl was so awesome, just saying, "hey, have you ever wondered why hjkl and ~home and esc key? Well, this is why."
2. It turns out that some of these original design decisions, made on systems with much more limited capabilities, are really efficient. HJKL, if you are used to it, is an order of magnitude faster than arrow key navigation when typing, because every time you want to use arrow keys you have to move your hand.
On the other hand, ~ being HOME is just historical cruft, as you say, and using the ESC key to exit insert mode is worse -- historical cruft that actually is worse and slows us down compared to, for example, using CAPSLOCK as many do instead.
No, but there is value in RTFM before you comment. The arrow keys work perfectly well in vim, and you're welcome to use them if you want. Page Up and Page Down too.
But at the end of the day, it's still just historical cruft. It's there, it won't kill anyone if it stays there, but it's not something awesome either. It's just an evolutionary dead-end; the male nipple of software design.
Did you miss the part where he explained why hjkl were more efficient than the arrow keys? It's right there in the part you quoted.
Kids these days. Next thing you know, you're going to be telling us you discovered a great new editor named emacs...
There's also a nice picture linked in the article in case anyone missed it.
I'm a full-time Linux user, so that's not intended as a dig against Unix, but merely an observation. Each of the traditional Unix utilities evolved from some earlier tool, and carries with it to this day both the quirks of its predecessors and many artifacts of the design constraints of the time. Some argue that this diminishes usability, and they may have a point. But I find that it gives Unix a certain charming character that I've grown quite fond of. I suspect this sentiment is fairly pervasive, and probably contributes substantially to Unix's resistance to change over time. Maybe it isn't the simplest thing to learn from scratch, but it's robust and highly dependable once you've learned it.
A much better introduction to the commandline is Neal Stephenson's "In the Beginning was the Command Line."
Read it here: http://www.cryptonomicon.com/beginning.html
Did you have a live terminal on the projector and demonstrate a few commands and then show how the output of one can be piped into another?
I'm interested in the balance between demo and explanation for this kind of audience.
Wonderful!
Special thanks for explaining the genesis of thos tools names.
Thanks, I've always wondered where "grep" came from! (But somehow have never gained the momentum necessary to look it up...)