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

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

[Russ Cox]

there's little function key support.
the function keys only got properly
handled in the keyboard driver two years ago.

the use of escape is a historical choice that i
don't fully understand.  (it's been in sam from
research unix, and i wasn't around then.)  maybe
someone else will comment.

> To: Russ Cox <9fans@cse.psu.edu>

hmm...  that works, i suppose, but it's not
exactly direct.

russ

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

[Matt H]

Hello Russ,

>> To: Russ Cox <9fans@cse.psu.edu>

oh sorry it's my email program being too clever

same with the subject line re[count++] idea

oh btw

cpu% upas/fs -f/pop3/post.proweb.co.uk/matt
upas/fs: opening mailbox: file does not exist

Which file? Vintage error message :-)
Since my patch problems I don't trust I have the latest version of
anything and that looks like the case here.



-- 
Best regards,
 Matt                            mailto:matt@proweb.co.uk

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

[Boyd Roberts]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
> the use of escape is a historical choice that i
> don't fully understand.  (it's been in sam from
> research unix, and i wasn't around then.)  maybe
> someone else will comment.

escape was used to do a select/snarf of text that had just
been typed.  i guess the case described of it cutting selected
text falls out of that principle.  ie.  escape is not a
'character', so the selected text is just cut.

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

[rob pike]

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

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

[Matt H]

Hello rob,


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

thanks rob. That has satisfied my curiosity. And that story is
fascinating really.

rp> Before this discussion devolves into the usual silliness, here's
rp> something fun we've been working on.

looks great, good idea.

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

[Randolph Fritz]

In article <20010519141427.A5005199C1@mail.cse.psu.edu>, rob pike wrote:
> 
> Are we settling in?  Does everyone agree that ^C is copy and ^V is
> paste?
>

Windows and Mac do...or more precisely, Mac uses command-C and
command-V; windows uses control-C and control-V.  (And Microsoft
changed midstream; their original choices were amazingly hard to type
and remember.)

One change it seems that could be easily made is the use of the PgDn
key for the "view" key; it is *extremely* confusing to go back and
forth to other systems that ues the downarrow key as a cursor
positioning key

IIRC, the Mac key choices were originally made on the basis of ease of
gesture by Tognazzini.

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

That was me. :-)

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

The last time this came up I had an off-group discussion of this; I
think some of the comments I wrote on this are relevant here.

>
> I've become frustrated with the lack of even simple cursor keys in
> Plan 9--for going one or two characters cursor keys are faster than
> mouse clicks.  (I've measured it--point and click is worth about six
> keystrokes, assuming no think time.)  On the other hand, having
> extensive cursor keys tempts one to use only cursor keys, but tests
> consistently show that that method of editing is actually slower than
> using a mouse, despite seeming faster.
[...]  
> [Keyboard shortcuts are] an accessibility need, I'd think--not
> everyone can use a mouse, and the chording is going to be difficult
> for many people with hand disabilities [including me!], quite apart
> from the RSI risks.
>
> In my personal opinion, the two-handed model of using the mouse for
> pointing, and doing operations like cut, copy, and paste from the
> keyboard has much to recommend it for users of typical physical
> ability.

Since we are discussing UI again, let me put in a plea for user
testing.  I don't even know how *I'll* respond to a new UI unless I
work with a prototype.  Arguing about UI without testing is a
high-entropy (high heat, low light) activity :-)

I have come to believe that both Unix and the Macintosh owe much of
their success to user testing, with very different groups of users.

Randolph

A few web essays on user testing, to start with.

http://www.asktog.com/columns/001closecoupledtesting.html
http://www.asktog.com/columns/037TestOrElse.html
http://www.useit.com/alertbox/20000319.html
http://www.useit.com/alertbox/20010204.html

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

[Matt H]

Hello Randolph,

Wednesday, May 23, 2001, 9:24:54 AM, you wrote:

RF> In article <20010519141427.A5005199C1@mail.cse.psu.edu>, rob pike wrote:
>> 
>> Are we settling in?  Does everyone agree that ^C is copy and ^V is
>> paste?
>>

RF> Windows and Mac do...or more precisely, Mac uses command-C and
RF> command-V; windows uses control-C and control-V.  (And Microsoft
RF> changed midstream; their original choices were amazingly hard to type
RF> and remember.)

I still find myself using Shift-Delete for cut, Shift-Insert for copy
and Shift-Insert for paste

I believe ^c ^v & ^x were taken from an IBM UI guide but someone else
might correct me.

-- 
Best regards,
 Matt                            mailto:matt@proweb.co.uk

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

[Boyd Roberts]

i'm suprised this subject hasn't degenerated into a total flamefest.

i think have things like ^c and ^v for copy and paste operations
are definitive proof that the UI is broken.  if it was easy to do
with the mouse why would you have such 'keyboard accelerators'?

i use them, but that's because it's easier than the various turgid
mouse driven GUIs and with a two button trackpad it's easier than
ctrl/tab + right button.  all these are indications of broken
interfaces or limited technology (ie. 2 button mice).

look around.  the 3 button mouse is nearly dead.  the closest seems
to be those horrible 2 1/2 button + wheel things -- ugh.

even with all that code that runs the trackpad i can't get it
to give me a middle button.  well i could [left+right], but then
i run out of fingers with which to select.