> I have also occasionally dreamed of a keyboard with LCD panels in
> each of the keys, though how to make it function reliably is beyond
> my electronics skill (so is just about anything in that field...)

I'm not sure LCD panels would be the way to go; I recall seeing an
article about what I might call "soft paper", something with the
form-factor of a sheet of paper but which changed what was "printed" on
it under computer control.  IIRC it was expensive, but everything is
when it's fresh out of the lab.

It might also be nice to have a self-luminant technology there rather
than a reflective technology, as long as I could arrange for the glyphs
to be light-on-dark (which, if they're soft, should be possible).

> For layout alterations though, it sounds as if you really want a
> touch panel, rather than a conventional (bits of plastic on spring
> loaded switches) mechanism.

For layout purposes, yes, I do.  But at least for me, usability
concerns override that, unless someone has come up with a way to give
touch panels travel characteristics basically identical to
plastic-on-springs.  I've used membrane and other zero-travel keyboards
and I...well, I won't say I hate them; they do have a place.  But
routine typing is not it, at least not for me.

And come to think of it, touch panels are lacking one thing
plastic-on-springs keys have: feedback permitting automatic correction
of small positioning errors.  If my fingers drift by a few mm, my
fingertips start feeling the edges of the keys rather than the centres,
and I adjust back; this has become automatic by now, but is
significant.  Not for nothing do membrane keyboards ring each key with
a raised ridge.

Now, given _good_ force-reflecting datagloves and a beefy enough cpu to
run the simulation, it could all be done in software.  However, as I
understand the state of the art in datagloves, particularly
force-reflecting datagloves and most especially anything good enough to
simulate the "edge of the key" feeling on one's fingertips, that's
quite a ways off yet.  Perhaps my knowledge is outdated - I don't often
want to be wrong, but this is one case where I'd be happy to be. :-)
It could be sorta cool to have new keys appear and disappear at
run-time, which not even my previous message's pipe-dream could do.

> And speaking of arrows, just to remain OT,

:-)  Anyone for offtopic@netbsd.org?

> an early system I used used the _ key as "erase character" - as back
> in those days, 0x5F hadn't really settled down as being "_" and was
> on some systems a (smallish) "<-" character [...]

I recall using glass-tty terminals that had a graphic like that on that
character code, though I never used anything that had picked that as an
erase character.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B