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.
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.
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,
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.
I loathe "it should be that way because it is that way" justifications, or arguments that defend appalling design with "oh you just need to get comfortable with how it works".
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.
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.
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.
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.
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.
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.