From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 10 Sep 1997 18:56:01 +0100
From: forsyth@caldo.demon.co.uk forsyth@caldo.demon.co.uk
Subject: [9fans] arrow keys
Topicbox-Message-UUID: 62b7ccb6-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19970910175601.Sah7gXfy2Xa21_rDTZBMDGvX4cbVSGz1rHvxjvvkk7g@z>

most keyboards here have the so-called UK layout,
not the US one, and some people found that confusing.
(i prefer the US layout and just touch-type, disregarding
what the key tops show.)  i therefore added a limited kbmap
device (/sys/src/9/port/devkbmap.c) and added an interface to it
to /sys/src/9/pc/kbd.c with other changes to allow
keys to be mapped to Runes, not just one byte characters.
that way some other european language keyboards could
be handled by loading the appropriate map into /dev/kbmap.
the mapping values are written to /dev/kbmap as text,
but the actual values are keyboard dependent (eg, PC/AT vs Sun's).
if you gloss over some possible laziness in the implementation, so far so good.

the arrow keys and function keys that take up an irritating amount
of space on the overblown PC keyboard are mapped by default
to non-graphic parts of the Unicode space.  (the
particular range i chose might not be the best choice,
but it's certainly much better than attempting cute mappings
to up and down arrow mappings, for the reasons rob has already
given.)

i implemented the keyboard mapping to allow non-American
keyboard mappings to be supported, and allocating distinct values
for the various function keys was only a side-effect.
i regard the arrow keys as there only because DOS needed them,
so i've generally ignored them.  it's obvious that people used
to them have programmed their body to head for the keys
when they make a mistake (it's easy to spot if you watch them),
in much the way i instinctively reach for the mouse by long practice.
even so, i'd be reluctant to introduce much support for them.
i once experimented a little, just to be nice to a few people to whom
i grudgingly decided to be nice, but i think it was a mistake.
there were always more complications (once you
came down to it) than they claimed there would be.  the mice and
arrow keys argue too much, and the arrows were originally intended
for use on a fixed-pitch rectangular character grid.  
in many applications there are several things that could be scrolled
by touching the arrow keys (eg, lists of news articles or mail messages,
as well as the message bodies).  on some non-Plan9 systems i've
used, the interpretation of the motion keys moves with the focus,
which commonly moves with the mouse (with or without a click)!
even worse are up & down movements in things like Word that
work with proportional text.  you need the computer's knowledge
of the details of the fount to know where the cursor will end
(if you experiment you see it's essentially a function of the last mouse click).
interaction of arrow keys with the current selection nearly always
leads to the introduction of yet more rules (``oh, you shift left arrow
to extend the selection to the right and control-left-arrow to
extend the selection to the left, and alt left arrow to trim it, and ...'').

a pox on the things.  give me back my desk space.