To understand the command line...(geekblog.oneandoneis2.org)
geekblog.oneandoneis2.org
To understand the command line...
http://geekblog.oneandoneis2.org/index.php/2012/09/30/to-understand-the-command-line
64 comments
I continue to use 'hjkl' to navigate in vi(m) because using the arrow keys requires me to move my whole arm. This is an awkward movement that requires time for my fingers to find the arrow keys. When using 'hjkl' to navigate, my right hand is always on home row, ready to either navigate or start typing. When typing in non-vi text boxes (such as this one), I do this movement, but I don't like it.
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.
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.
Remap caps lock to escape. After I did this I realized Esc is a really useful key in a wide variety of contexts.
make capslock to contorl, then use xcape
https://github.com/alols/xcape
now capslock does both ctrl and escape
best settings ever!
https://github.com/alols/xcape
now capslock does both ctrl and escape
best settings ever!
One of the best ideas I ever had. Caps Lock is one of the biggest keys on my keyboard and close to the rest. It would be a waste to use it for a single, rarely-used function.
Capslock is already ctrl.
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.
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.
Try:
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.
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 started using inoremap jk <Esc>
I'm not sure why, but I found it to be more fluid for me?
I'm not sure why, but I found it to be more fluid for me?
inoremap jj <Esc>
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!
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!
I like to use hjkl for very short moves, wb for most moves in a sentence, "IA" for insert moves to the start or end of a line. I don't find f to be that useful because I don't like the thought required to figure out what letter I want. I guess it's just a personal preference though.
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.
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.
You could use Ctrl+C which works great for getting out of insert mode. Also Ctrl+J can be used instead as Enter. It also does work great in bash/zsh. It took me some time to switch but it was totally worth it.
Caution: Switching caps lock with control was needed as prerequisite.
The downside of ^c is that it doesn't trigger an InsertLeave event or abbreviations. Which can be a pain, or exactly what you want, depending on the occasion.
After switching between keyboards with Esc in different places, I've learned to use
The only downside is being confused when nothing happens in a browser...
Ctrl-[
The only downside is being confused when nothing happens in a browser...
I learnt that `Ctrl-W` removes a whole word backwards in vim and the terminals.
The only downside is being confused when
The only downside is being confused when
Remap caps lock to control and use ^c or ^[
it's not something awesome either. It's just an evolutionary dead-end; the male nipple of software design.
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 :)
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 :)
Well...
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.
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.
It's unfortunate vi uses arrow keys are in a non-intuitive layout. Still - it is a good idea to steer users away from arrows, inclduing to disable them in default files if you're mentoring.
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.
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.
Still - it is a good idea to steer users away from arrows, inclduing to disable them in default files if you're mentoring.
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.
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.
OK thanks for clarifying. I understand your point better where I missed it before.
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,
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.
Touch-typing. It's difficult to relate to if you cant touch-type. Expert typists loathe taking their fingers off the middle row; using the arrow keys(or any other navigation keys) means taking your fingers off.
I would counter that with computer gaming. Everyone who plays computer games growing up would be familiar with the keypad, the arrow keys, or WASD. In all cases, UP is always above DOWN.
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.
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.
Oh I agree it's not for everyone. I'm just saying what might be the reason from a historical perspective.
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.
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.
Yeah, I think UHJK might really make the most sense.
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
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
Another proposal: IJKL. Your fingers don't move off the default home position.
True, but somehow I am more willing to rebind undo than insert; I am not sure this is logical. I also do like the h,ctrl-h and j,ctrl-j correspondences I mentioned - helps me remember the values in question when working with ascii (ctrl-a = 1, ctrl-b = 2, etc).
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.
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.
How about straight up WASD? It is already a defacto standard anyway.
I find the switch between hjkl and uhjk easier than the switch between asdf and wasd, but that could just be me.
Outside of games, I can't think of anything that uses WASD.
About those keys - with the possible exception of S - all those keys are tied to significant functionality you wouldn't want to replace.
About those keys - with the possible exception of S - all those keys are tied to significant functionality you wouldn't want to replace.
It's pushing her away from what every other bit of software on her system, including the OS itself, has trained her to do
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.
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.
You mean down/up 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.
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.
> this one program
/usr/games/robots
/usr/games/robots
Non-intuitive? ASCII ^H is Backspace, which moves left, and ^J is line feed, which moves down. How much more intuitive can you GET?!?
vi/vim allow you to use the arrow keys for navigation if you want to. The choice is yours. I prefer keeping my fingers on the home row, and so I find hjkl to be much more efficient, especially on a laptop where the arrow keys aren't usually physically separated from the rest of the keys.
Also, you can't have fingers on all four arrow keys at once, while you can with hjkl. It's not only more ergonomic in the sense that you move your arm less, but also because you move your fingers less.
I'd rather use ASDF but those keys are taken by other vi commands. Anyway, is there a way to press "Esc" without moving your whole arm?
A lot of Vim users remap <caps lock> to <esc>.
I advocate remapping jj to escape.
Put this in your .vimrc or just try it out from the command bar:
inoremap jj <Esc>
Put this in your .vimrc or just try it out from the command bar:
inoremap jj <Esc>
For reference, here's the keyboard layout of the ADM-3A terminal: http://en.wikipedia.org/wiki/File:KB_Terminal_ADM3A.svg
There's also a nice picture linked in the article in case anyone missed it.
There's also a nice picture linked in the article in case anyone missed it.
sounds like an emacs user... :)
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?
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...
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...
Pretty much any question about why things are done a particular way in Unix can be answered the same way: "for historical reasons".
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.
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.
This article assumes the reader already knows a lot about the CLI.
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
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
Well, in fairness, I did write it for a Linux User Group :)
How did the, er, extended description of the last 10 minutes of the film adaptation of The Lord of the Rings go down?
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.
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.
You should make it clear that while Thompson did allocate a week to the editor, he did not write vi--although one might think so, with that quote coming right in the middle of a block about vi.
> This is bad, because it means that the difference between a master and a beginner is almost nothing.
Wonderful!
Special thanks for explaining the genesis of thos tools names.
Wonderful!
Special thanks for explaining the genesis of thos tools names.
So the "show me matching lines" functionality, which ed users made massive use of, could be summed up as "globally search for the regular expression and print it" - or, in ed format, g/regular expression/p. Or, to shorten it a bit more, g/re/p
Thanks, I've always wondered where "grep" came from! (But somehow have never gained the momentum necessary to look it up...)
Thanks, I've always wondered where "grep" came from! (But somehow have never gained the momentum necessary to look it up...)
Hahaha, same. This article was full of answers for me regarding Unix stuff that I use everyday and was only half-curious of their origins but never cared enough to look up. Articles like these are the best.
Nice article, for a better understating of Unix and its history I recommend the awesome UNIX-HATERS Handbook (http://m.simson.net/ugh.pdf).
[deleted]
Where's the spoiler alert? Psh. No need to watch LOTR now... :)
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.