Re: Re[4]: [9fans] home, end ^h^j^k^l

["rob pike" <rob@plan9.bell-labs.com>]

Yes, the behavior of the escape key (selecting typed text when nothing
is selected; deleting it when something is), backspace, typing when
text is selected, all this and more comes from Smalltalk, which was
the nicest thing to take ideas from when the precursors to all this
software were written, back in the early 1980s.

My primary regret is in this area is the different behavior of ESC
between sam and acme vs.  rio.  Rio's use of ESC is a great feature,
but it should have been placed on a different key.  But then, which
key on which keyboard...?

> Is it that the people who made the choices used different keyboards to
> the WinTel world?

Yes. The lack of support for Insert, Delete, the Windows key, End,
Page Up, etc.  all stem from the lack of those keys on the keyboards
this software was developed for.  (Plan 9 didn't even run on PCs in
its early days, and I bet the Windows key didn't exist before
Windows.)  Also in the early days of Plan 9 there was a variety of
machines (now, sometimes it seems PCs are the only machines in the
world) and a consequential variety of keyboards.

Are we settling in?  Does everyone agree that ^C is copy and ^V is
paste?  I doubt it.  Do we know that all keyboards will have the keys
we need?  I'm not sure.  Seems like you should decide what features
you want in your user interface, and map those to the available keys,
rather than the other way around.

There are a few decisions I made in Plan 9 that I expected to get
blasted on but that turned out not to generate much heat.  One of
those is that there is no equivalent of stty; the control codes are
fixed in the software.  My argument was that the complexity isn't
worth the convenience; you'll learn what keys do what and adapt.  Let
the other systems use stty to match Plan 9; they're all so proud of
that interface.

I wrote a paper called "Window Systems Should be Transparent".  It's
on my web page; go have a look.  (It predates Plan 9.)

> functioning cursor keys would still be a speed benefit.

This feels true but is false.  There were some fascinating experiments
done a few years ago in which people were given a long, tedious
editing task.  Some of the people were keyboard fans, some were mouse
fans.  Both folks were asked to do the task two ways, in random order,
once using the mouse to do the editing, once using cursor keys etc.
Regardless of their predilections, which was stated up front, after
the experiment everyone who did the task agreed that it was faster to
use the keyboard than the mouse to complete the task.  Everyone.

Here's the kicker: everyone was wrong.  They were being timed, and in
fact the reverse was true.  Although they thought the keyboard was
faster, doing the task using the mouse was faster for everyone, by a
substantial fraction.

The explanation, besides the obvious that arrow keys are actually
pretty slow if you're going more than a line or character, is that
people feel the mouse wastes time because you need to grab it and move
it, but it's time well spent.  The part of the brain that uses
keyboard commands to move the cursor is a higher-order function, and
thinking and planning how to use the keys to get to the destination
blocks thinking about the editing task at hand.  But using the mouse
is done by a lower-order part of the brain, which keeps the editing
part of the brain clear.  There's less task switching going on when
you use the mouse, so you work more efficiently.

If you don't believe me, the story is here:
	http://www.asktog.com/readerMail/1999-12ReaderMail.html
Thanks to some forgotten 9fan who mentioned this a while back.

I didn't know about these experiments when I said, long ago, that
using arrow keys to point at a display is like telling someone how to
go somewhere by giving directions, while using a mouse is like
pointing at a map.  In fact, I never used a screen editor until I had
a mouse, for just this reason.

Before this discussion devolves into the usual silliness, here's
something fun we've been working on.  Who last modified those ether
drivers?

	pc% ls -m ether*.c
	[sape]     --rw-rw-r-- M 2812 sape sys  2820 Apr 18 12:23 ether2000.c
	[sean]     --rw-rw-r-- M 2812 sape sys 34782 May  3 10:19 ether2114x.c
	[sape]     --rw-rw-r-- M 2812 sape sys  4644 Apr 18 12:23 ether589.c
	[sean]     --rw-rw-r-- M 2812 sape sys 13352 May  3 10:18 ether79c970.c
	[sape]     --rw-rw-r-- M 2812 sape sys  6665 Apr 18 12:24 ether8003.c
	[sean]     --rw-rw-r-- M 2812 sape sys 25364 May 17 10:15 ether82543gc.c
	[presotto] --rw-rw-r-- M 2812 sape sys 28587 Apr 23 13:52 ether82557.c
	[sape]     --rw-rw-r-- M 2812 sape sys 17544 Apr 18 12:24 ether8390.c
	[jmk]      --rw-rw-r-- M 2812 sape sys  3745 May  2 17:02 etherec2t.c
	[sean]     --rw-rw-r-- M 2812 sape sys 47826 May 17 10:14 etherelnk3.c
	[jmk]      --rw-rw-r-- M 2812 sape sys 24348 May  2 16:59 etherga620.c
	[sape]     --rw-rw-r-- M 2812 sape sys 15079 Apr 18 12:26 ethersmc.c
	[jmk]      --rw-rw-r-- M 2812 sape sys 28045 May  8 13:18 etherwavelan.c
	pc% 

The -m flag reports the muid (modifier uid) of the file, as reported
in the new 9P protocol.  This is the person who most recently modified
the file, instead of the person who created it.

History reports the information over time:

	pc+% history ether82557.c
	Apr 23 13:52:18 EDT 2001 ether82557.c 28587 [presotto]
	Apr 23 13:52:18 EDT 2001 /n/dump/2001/0519/sys/src/9/pc/ether82557.c 28587 [presotto]
	Apr 18 13:33:20 EDT 2001 /n/dump/2001/0423/sys/src/9/pc/ether82557.c 28510 [jmk]
	Feb 28 18:40:30 EST 2001 /n/dump/2001/0418/sys/src/9/pc/ether82557.c 28445 [jmk]
	Nov 11 10:30:56 EST 2000 /n/dump/2001/0228/sys/src/9/pc/ether82557.c 28058 [sape]
	Jun 19 00:05:20 EDT 2000 /n/dump/2000/1111/sys/src/9/pc/ether82557.c 28058 [jmk]
	...

The history command could now be renamed 'whotoblame'.  And as always,
history -D will tell you why to blame them.

-rob