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

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

[Matt H]

Hello 9fans,

  here's my question for today

  over the years i've rather got used to home, end and the cursor
  keys. I find it slightly cumbersome so reach for the mouse to move
  up a line in acme and I keep instinctively press the up key and lose
  my concentration when I find myself a page away.

  So, is there a simple way to enable those keys to move as I expect
  them to (without hacking the source)?

  If not then my supplementary is why?
  What's the philosophy of not allowing the cursor keys to move the cursor?

  Same goes for the shell. I love the freeform nature of it but really
  miss home and end. Ctrl-U is about as good as it seems to get.

  I hope I'm missing something, I'd be disappointed to lose out on all
  that keyboard training.

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

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

[Chris Locke]

One thing in acme that quite often bites me is the tendency when
chording a cut for the cursor to drop onto the line below and cut
much more than I intended.

I must have a tendency of keeping the cursor close to the bottom of
the line when making a selection. The action of chording the middle
button is often enough to drop the cursor down a fraction onto the
lower line, just as the cut is done.

One thing that would make this much less likely to happen was if there
were some hysteresis in selecting across lines. i.e. the selection
would only extend into another line when the cursor had moved a
few pixels vertically into it.

Perhaps I should just be more careful!

What are other peoples most common acme 'gotchas'?

Cheers,
Chris.

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

[Scott Schwartz]

| One thing in acme that quite often bites me is the tendency when
| chording a cut for the cursor to drop onto the line below and cut
| much more than I intended.

I've noticed that too. It also happens between characters on the same
line.  Your hysteresis idea seems plausible.  Send patches!

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

[Matt H]

CL> What are other peoples most common acme 'gotchas'?

my other one is one I'm learning to deal with

in windows if you select some text and press backspace you delete the
selected text. If you select some text in acme it replaces the current
text with a backspace so it also deletes the character to the left of
your selected text. So, as you must do, I select one less then the
ones I want to delete.

functioning cursor keys would still be a speed benefit.


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

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

[Quinn Dunkan]

> CL> What are other peoples most common acme 'gotchas'?
> 
> my other one is one I'm learning to deal with
> 
> in windows if you select some text and press backspace you delete the
> selected text. If you select some text in acme it replaces the current
> text with a backspace so it also deletes the character to the left of
> your selected text. So, as you must do, I select one less then the
> ones I want to delete.

Nowadays, I get surprised by Linux and Windows when backspace doesn't
delete backwards like it's supposed to.  Plan9's behaviour works nicely
for deleting words.  Otherwise, I've learned to use a cut chord, which
only removes that which is selected.  Since you're using the mouse
for selecting anyway, it's easy to just cut out your text.

> functioning cursor keys would still be a speed benefit.

They do function!  Oh, you mean functioning *your* way ;)


My acme gotchas:

Deleting text with backspace replaces the snarf buffer.  I often cut out
something I want, and then do some editing to prepare a place for it, and wind
up deleting a space or something, at which point my paste doesn't give what I
expected.  I don't think the snarf buffer should be quite so ephemeral, but it
probably also has something to do with how I work (i.e., if I want to snarf
something, I snarf, and if I want to delete it, I delete).

New windows rarely appear where I want them.  I gather the heuristic is
optimized for a particular pattern of use, and I recall seeing that
documented somewhere, but can't find it now.

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

[Matt H]

>> functioning cursor keys would still be a speed benefit.

QD> They do function!  Oh, you mean functioning *your* way ;)

no, I meant that the cursor keys move the cursor

I'll accept that maybe on average the mouse might be quicker but to
move 1 character in any direction but I'm stopping talking now :)

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

[Boyd Roberts]

> no, I meant that the cursor keys move the cursor

with glass ttys you learnt pretty quickly not to use
them across tcp connections.  things like vi would use
a timer to collect a multibyte [arrow key] sequences.
bad stuff would happen if part of the sequence arrived
late.

if you take this 'put it all on the keyboard' philosophy
to the limit you'd have an unworkably large keyboard,
and it'd always be missing a key.

it'd probably be easier to move to japan.  some of
the keyboards are something else; overlays to re-map
the array of functions/keys/...

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

[Douglas A. Gwyn]

Boyd Roberts wrote:
> > no, I meant that the cursor keys move the cursor
> with glass ttys you learnt pretty quickly not to use
> them across tcp connections.  things like vi would use
> a timer to collect a multibyte [arrow key] sequences.
> bad stuff would happen if part of the sequence arrived
> late.

That is an artifact of a certain combination of historical
design errors, and need not affect use of the modern
workstation where each keypress is encoded in a single datum.

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

[Douglas A. Gwyn]

Quinn Dunkan wrote:
> Deleting text with backspace replaces the snarf buffer.  I often cut out
> something I want, and then do some editing to prepare a place for it, and wind
> up deleting a space or something, at which point my paste doesn't give what I
> expected.  I don't think the snarf buffer should be quite so ephemeral, but it
> probably also has something to do with how I work (i.e., if I want to snarf
> something, I snarf, and if I want to delete it, I delete).

It's not just you; I keep running into this problem using "sam".
Partly it's coupled to the behavior of backspace for a highlighted
region: to exactly delete what is highlighted, one has to cut it,
which overwrites the snarf buffer.
I would actually prefer an array of snarf buffers (a la TECO's
Q-registers), but then the complexity starts to overwhelm the
user.  I doubt it is possible to design a *small* interface that
best fits all usage patterns.

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

[Boyd Roberts]

From: "Matt H" <matt@proweb.co.uk>
> in windows if you select some text and press backspace you delete the
> selected text. If you select some text in acme it replaces the current
> text with a backspace so it also deletes the character to the left of
> your selected text. So, as you must do, I select one less then the
> ones I want to delete.

no, you hit cut.

plan 9 gets it right, windows gets it wrong.

plan 9 replaces selected text by the typed text.  if the replacement
text is a backspace then it does exactly as advertised.  ie. there is
no special case for backspace.  special cases are a curse.

consider how drag and drop works on windows with the file mangler.
it does a copy if you drag from a: to c: but it does a move if you
drag and drop on c: -- totally counterintuitive.  it would be like
if cp(1) made an excutive decision based on source and target.

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

[Boyd Roberts]

forget termcap

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

[Russ Cox]

> in windows if you select some text and press backspace you delete the
> selected text. If you select some text in acme it replaces the current
> text with a backspace so it also deletes the character to the left of
> your selected text. So, as you must do, I select one less then the
> ones I want to delete.

type "esc", but beware that cuts it
rather than deleting it (i.e., it ends
up in the snarf buffer).

russ

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

[Matt H]

Hello Russ,

RC> type "esc", but beware that cuts it
RC> rather than deleting it (i.e., it ends
RC> up in the snarf buffer).

well you guys sure chose some crazy things :-)

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

I've often breated my keyboard for not having such sensible keys as
cut copy and paste already on the keytops. To then move to one where
Insert, Delete just display graphics makes me curious.

If not noticed what function key support is like in plan9.
Assigning cut snarf paste new etc. to whichever function key I want
would be cool.


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

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

[forsyth]

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

smalltalk80 used esc to select the most recently typed text,
and ``destructive backspace'' also deleted the character preceding
the selection (makes sense given an empty selection);
``delete'' cut the current text selection.

smalltalk80 implementations typically didn't implement cursor keys,
or at least the one i tried briefly,
sensibly enough since most of the keyboards hadn't got them  (whooo!)
(like my Happy Hacking kbd now).  the cursor keys were needed
by DOS and many glass teletypes because they moved a blob cursor
round the screen.

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: Re[4]: [9fans] home, end ^h^j^k^l

[James A. Robinson]

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

That's pretty cool. I suppose it would be a waste of space to
record who deleted a file as well? One of the problems we had
to deal with twice over the years is someone accidently deleting
important files, but never coming forward. Sifting through process
logs was a not a lot of fun. =)


Jim

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

[Boyd Roberts]

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

now, that looks cool.

with that and /n/dump it would obviate the need for *cs.

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

[Richard Elberger]

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

I worked in software internationalization (in software release management)
for a few years and it just wasn't char set issues, it was hardware as well.
Our inventory of keyboards in the lab was huge.  This is why the mouse (or
other type of pointing device) is really nice.  It really reduces the
problem of having to track all the keyboard dependencies -- *if* the
pointing device is reliable and the application was built with functionality
being run by a pointing device.  I think that stuff like ^C has become a
learnt evil with the most common OS's and shouldn't be a requirement in the
next generation simply because it's habit.

-- rich

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

[Boyd Roberts]

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

nah, call it 'culprit'.

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

[Lucio De Re]

On Sat, May 19, 2001 at 10:14:25AM -0400, rob pike wrote:
> 
> 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:
> 
Wow!
> 	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.
> 
Now you just have to have incremental diffs (yes, I know about dump,
just add file-close granularity) and file qualifiers (I forget
what the Macintosh calls them, but in CP/M it is extensions) and we
can take over the world.  Oh, people also ask for ACLs :-)

++L

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

[paurea]

rob pike writes:
 > From: "rob pike" <rob@plan9.bell-labs.com>
 > Subject: Re: Re[4]: [9fans] home, end ^h^j^k^l
 > Date: Sat, 19 May 2001 10:14:25 -0400
 > 
 > 
 > 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.
 > 

I've read this argument before and conducted some experiments on my
own. I agree that it is faster to use the mouse than the arrow keys on
some cases.  When I am in emacs, for long jumps I use some other
method which is faster some times. I normally type C-s and search for
a word. (typing it repeatedly looks for the next match). My
conclusions are that, for local moves of two or more characters, the
C-p C-f (the emacs equivalents to arrow keys) are faster. For long,
like modifying two paragraphs at the start and the end of the text, ,
C-s is best, specially if you can't see where you are jumping (it is
one or two pages away).  For midrange jumps, moving to somewhere you
can see on the screen, specially if you are jumping here and there,
the mouse is much faster than any other thing, even more if you are
cutting and pasting things around.

Something else which is fast and I use a lot in emacs, is C-a and C-e,
to go to the starting and end of the line.

Taking the hands away from the letter keys, even to the arrows is time
consuming. More than the act of moving them, the time it takes to
accomodate them back on the keyboard to start typing again. Another
thing which takes time is the difficulty to be precise with the mouse
(this depends on the resolution the screen is at). On the other hand,
the cursor moves itself at a more or less constant rate and that makes
it slow too. It is also very distracting because you have to keep
your attention on it to stop it on time. 
-- 
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"
-- 
    /"\
    \ /    ascii ribbon campaign - against html mail 
     X                           - against ms attachments
    / \

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

[Boyd Roberts]

From: <paurea@dei.inf.uc3m.es>
> I've read this argument before and conducted some experiments on my
> own. I agree that it is faster to use the mouse than the arrow keys on
> some cases.  When I am in emacs, for long jumps I use some other
> method which is faster some times. I normally type C-s and search for
> a word. (typing it repeatedly looks for the next match).

any set of convoluted operations may be faster in a given circumstance.

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

[Boyd Roberts]

> pc% ls -m ether*.c
> [sape]     --rw-rw-r-- M 2812 sape sys  2820 Apr 18 12:23 ether2000.c

put the muid after the gid or just before the mod time.

i think i prefer after the gid:

    - the 3rd name should be obvious, given the first 2 should be
      engraved on everyone's psyche

    - puting it near the mtime is probably bad, 'cos it's not
      always an mtime.

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: Re[4]: [9fans] home, end ^h^j^k^l

[rob pike]

> That's pretty cool. I suppose it would be a waste of space to
> record who deleted a file as well?

The directory will have its muid set to the most recent deleter or
creator of a file within.  There's no other obvious place to record
the information for deleting a file, since the file is gone.

-rob