OSNews

Yes, ^M = 13 (carriage return). Similarly, ^H = 8 (backspace) and ^I = 9 (tab).

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.)

The LK201 keyboard of the DEC VT220 was the first keyboard to feature the inverted T arrow cluster. It was inspired by some researchers who looked at arrow key usage by users of VMS' text editor.

You can still use the arrow keys if you like.

Yet they behave differently. One remembers cursor location when moving between lines, the other one does not.

Your comment confused me so much I had to go and check. Nope, the arrow keys act identically to hjkl.

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.

It's entirely possible it could have worked that way.

Vi setups vary depending on the preferences of the person writing the config file and what program is impersonating vi.

Of course if you do, you'll have to move your hand off home row and slow yourself down considerably. =)

So what are you saying? Using hjkl worked fine in those days, but now that we have dedicated arrow keys it doesn't work anymore?

Byt the way, Vim doesn't enforce it; if you would like the arrow keys, you can... One could only argue that is not the vi way to navigate, though.

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. :-)

Doc Pain,


"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.

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).



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).



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



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.



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. :-)

I usually map "Caps Lock" to "Escape" (using xmodmap). Caps Lock is useless anyway (at least for me) and this decrease travelling distances significantly.

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.

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



You can also use Ctrl-[ as an ESC equivalent.

Unless you're using a Televideo 950. On that terminal, [ and ] are on the same key. Ctrl-[ will send Ctrl-], regardless of shift.

Not that I'm bitter or anything...

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.

"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)


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)

Edited 2012-03-16 23:54 UTC

I was equally excited to discover that ~ is the HOME key on the ADM-3A. Yay! More usual trivia to annoy people with!

I could have been interested in the resulting discussions about high-resolution screens and current tablets being intentionally crippled machines, but then the SNR just became too low.

Edited 2012-03-10 08:29 UTC

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.

You do realize that 'i' is missing from hjkl, right? And 'e' from dfgh? If you're going to allow omissions, erty also qualifies.

Notice that only one character is missing from the exact same space in the sequence in both cases. So both sequences map properly.

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.

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.

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.

Yes "an acquired taste" explains it perfectly.

I'm not a fan of vim, vim just seems to large for me. ;-)

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.

Edited 2012-03-10 11:06 UTC

And/or it's largely an illusion: http://plan9.bell-labs.com/wiki/plan9/Mouse_vs._keyboard/index.html ...your mind is occupied more by such editors, hence yeah, "and it happens" because there was not a lot of free cognitive processing left to notice much else.

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)

Edited 2012-03-17 00:11 UTC

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.

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 )

Edited 2012-03-17 00:05 UTC

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.

You want to move 10 rows from line 25 to line 50?

25G
10dd
40G
p
:wq

'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.

I really dislike people who do that with shared files, like the files in /etc on a Unix system.

It is way too easy for two people to make changes and the last guy overwrites the file.

If both people are using vi it will warn about a swap file in use. Other editors will (sometimes) warn that the file changed while being edited. But the upload and overwrite trick never does.

I agree you need a (editor-agnostic) 'check whether the file changed while I was working in it'. Of course you can have that with editors that do 'upload and overwrite' too.

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.

- Gilboa

Edited 2012-03-10 14:36 UTC

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.

Edited 2012-03-11 06:45 UTC

I don't even use colorcoding.

There is one thing I do want to use a GUI for.

Doing lots of large merges.

Do you have any recommended tooling for doing merging ?

I've yet to find anything which fits what I need.

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.)

P.S. Quick summary: http://www.longwood.edu/staff/pedenjh/basic_vi.html

Don't trust him, Emacs is the best editor.

Maybe OSNews isn't Slashdot ;-)

I always work in Emacs but use Vim for quick edits. Just now I accidentally started vim within an Emacs shell. I think I'll be reported for blasphemy.

Maybe just call it syncretic (kinda like... virtually every single religion, big time) and be done with it ;p

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).

Perhaps that just means people tend to have more issues when trying out vi and related ;p

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.

ed won.