And yet I read, on Hacker News, a number of people writing how they were often saved by the availability of nano on random systems
All the time, but I even use nano all the time on OS X for full on programming, mostly for quick edits or starting things off before I can be bothered opening a full project in Sublime. (Sure, I can 'get around' in vi, but I just don't seem to have the brain for it and nano is 90% fine. I grew up on GWBASIC so anything is an improvement ;-))
That aside, this feels like it could be a kinda cool command line level equivalent of ToDoMVC. Port this simple editor into Go, Rust, and a few similar languages - see what the differences are, etc.
Nice thing about Nano is that they arrow keys always seem to do what they are supposed to, no matter the system, shell, TTY, etc. Vi seems to have issues sometimes, and needs extra config
I always try to remember them by noting that the leftmost key moves left, the rightmost key moves right (not too hard), and that 'K climbs' (using alliteration to remember that). That leaves 'J' for cursor down.
In practice, though, I use the cursor keys. Luckily, they work on the editors/systems I work on nowadays. Side effect is that I am very bad at remembering those mnemonics.
I stole the following from a colleagues `.vimrc` which finally allowed me to learn `hjkl`. Now I forget I have this set, and when I do accidentally use an arrow key it makes me laugh.
The point is, they are no longer in symbolic memory. At this point they are muscle memory. Quick, which muscle do you use to move your right thumb in? Does it matter?
Exactly: muscle memory. In your car, do you move the turn signal lever up or down to indicate a right turn? It actually takes longer to answer this question than to do the action in real life.
Another example: There are several passwords that I can type instantly, but I wouldn't be able to recite them.
h is left because it is on the left of the movement keys, l is right because it is on the right of the movement keys... a fairly convenient correspondence.
Just have to imagine the motion. I remember left/right by literally right clicking & feeling my middle finger be to the right of my index. I got a little mixed up when I switched my mouse to my left hand
I use hjkl consistently in vim and in the shell. Just think about how long it takes you to move your fingers to the cursor keys. You should spend some effort getting used to it, as using hjkl means you can keep your hands in the middle of the keyboard. I have also never had any problems with strain, and I suspect this is part of the reason.
Erm... what? I didn't claim it's more usable (though it is for me). I just
provided mnemonics I saw once which I liked, for a question "which k/j moves
up and which moves down?".
The leftmost one is left, the rightmost one is right. Of the two that remain, the one that looks vaguely like an arrow pointing downward, that one goes down. There's one key remaining, and that one goes up, k?
As everyone says, it doesn't take a lot of practice before you know it well enough that you'll never forget. Unbind the arrow keys, or go play some nethack (no-keypad), or whatever.
I know k is up, because I constantly <ESC> k in bash, bit the point of using hjkl is exactly not to know which one is what. You set your finger on the keyboard in home position, now your muscle memory does the rest.
The poster probably changed his bash to use vi editing mode with set -o vi. In this mode, <ESC>k would put the text of the last command entered back on the prompt.
> Have you seen somewhere where that isn't the case?
I use the dvorak keyboard layout and used to remap (among other things) j and k in vim, since they were not on the home row for me. I stopped doing that after a while though.
If you ever happen to bork your kernel badly enough to prevent it from booting, you'll find a classic VI pretty quickly, and probably be grateful for it.
Well, not really. My system doesn't have vi installed. Vim, of course, any
time of the day. Stripped Vim (vim-tiny, as Debian calls it), sure, just after
installation. But vi -- no, I don't have it installed.
For quite a long time Linux didn't have vi even ported. There were several
clones, like Elvis and nvi (and Vim, of course). Few years ago I learned that
somebody took the effort and actually ported traditional vi to Linux. I doubt
mainstream distributions cared to include it, though. Why should they? They
already have plethora of clones packaged, and those clones typically do much
more than traditional vi.
The lesson from this tale is this: don't call vi what is merely a vi clone. vi
is a name of a quite concrete project.
And as for kernel unable to boot: if it can't boot, then how the heck am
I supposed to run anything under this kernel? Unless you meant kernel can't
run OS from local disk. I know Linux well enough to manage to run my things.
You would be surprised how much could you hack through if you knew how ELF
binaries work.
You are being needlessly pedantic. The point is that typing "vi" into a terminal runs some application that implements a "vi-ish" interface. Whether it is ported vi or vim or vim-tiny has some effect on how nice that interface is to work with, but I would argue that most vim users would be able to get their configuration fixed or whatever
I assure you I am not pedantic needlessly. The claim was "vi has some issues
with arrow keys". Now tell me: which vi clone was elsurudo talking about?
Because those are different projects. And Vim doesn't have a smallest issue
with arrow keys (unless with "compatible" option set, I think, but I didn't
use it for years and I may remember wrong).
All the time, but I even use nano all the time on OS X for full on programming, mostly for quick edits or starting things off before I can be bothered opening a full project in Sublime. (Sure, I can 'get around' in vi, but I just don't seem to have the brain for it and nano is 90% fine. I grew up on GWBASIC so anything is an improvement ;-))
That aside, this feels like it could be a kinda cool command line level equivalent of ToDoMVC. Port this simple editor into Go, Rust, and a few similar languages - see what the differences are, etc.