[I'll reply to your email separately...] Sorry for not sending the results I had earlier re parsing input keys. Just to get this recorded here in case someone wants to do this in the future:
I was first optimistic about the prospect of parsing keys in a way that
works for all terminals, provided that it's limited to the few keys that
are needed for line editing. I wrote some code to parse terminfo texts
which I extracted on my linux installation, and find conflicts. Turns
out that it's easy to do what I wanted only for the arrow keys, but then
things got very messy. Specifically, there are terminals that use the
opposite escape sequences for home/end or backspace/delete. (My best
guess about the origin of some of this is that there were numeric pads
that were laid out top-to-bottom as in phones, and the escape sequences
were based on the kp keys.) It might be that the really bad conflicts
were happen with irrelevant terminals, but there are definitely
conflicts involving terminals that are relevant, like xrvt and
gnome-terminal.
My conclusion is that even for a very simple thing you need to consult
$TERM to know what to do, and some simple attempt to do that would most
likely evolve into some form of a terminfo-like facility. So it's
better to just write something that can deal with terminfo directly.
FWIW, I don't think that it's too hard -- specifically for reading keys,
it's straightforward since you just get the escape sequence that you
need to identify on input.
I'm attaching the code that I wrote. (To run it you might need to
adjust the location of the terminfo files at the top of the code; also,
it relies on "infocmp" as a way to print them out.) If you run it you
get a huge listing of all keys, with indications about conflicts. The
reallly bad conflicts would be cases where some escape sequence is a
prefix of another -- and those are rare (look for "prefix") and happen
only with some obscure F keys. (I initially just looked at these which
is why I thought that it's doable.)
Also, the `parse-decisions' thing in the code is my attempt to encode
how a parser should work and have it show the rest of the conflicts. I
planned to add more keys and keep minimal conflicts but then I got to
the ones that don't have a good solution. As an example, this part of
the output:
<end>:
\eOq (!! (aterm mrxvt rxvt ... xterm-xi):
clash with <home> of (nsterm ... vt102))
(!! (aterm mrxvt rxvt ... xterm-xi):
clash with key_f0 of (xterm-r5))
\e[4~ (!! (... cygwin ... linux putty ... xterm-vt220):
clash with key_select of (... aterm gnome ... rxvt ...
xterm-24 ...))
shows one of these problems, where <end> on rxvt (popular enough)
correspond to <home> on vt102 (popular emulation target), and the last
thing shows a conflict between cygwin/linux/putty (all popular) and
aterm/gnome/rxvt (popular too).
[Extended footnote re time investing in this nightmarish pit of depair:
If you stare at this for a while, and consider using these results,
you'll get a feeling of how bad it can be... Maybe vt102 is not used
too much? Would there be any need for a "select" key, or maybe the same
escape sequence is mapped to something else that is useful?
The bottom line is that I don't really reject the noiseline-style
attempt to get something that works for "most usert" -- it's the
blindness of going in that direction and thinking that you *won't* fall
into this trap. (Or, if you really won't since you'll refuse to
accomodate bugreports, then you'll make someone else fall into this trap
because of you.)]
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
std-keys.rkt
Description: Binary data
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
