From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: Re[4]: [9fans] home, end ^h^j^k^l From: "rob pike" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20010519141427.A5005199C1@mail.cse.psu.edu> Date: Sat, 19 May 2001 10:14:25 -0400 Topicbox-Message-UUID: a1f05e74-eac9-11e9-9e20-41e7f4b1d025 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