On Fri, Apr 18, 2008 at 02:02:37AM +0200, Bram Moolenaar wrote: > The current termcap/terminfo implementation is terribly outdated, > obviously, but that doesn't mean we now should drop the idea and > set the escape sequences in stone.
Right. Then add the following to xterm's terminfo database:
is_csibased
keycsi_up=A
keycsi_down=B
keycsi_left=D
keycsi_right=C
keycsi_end=F
keycsi_home=H
keycsi_ins=2~
keycsi_del=3~
...
keycsi_unicode=u
...
keymod_shift=1
keymod_alt=2
keymod_ctrl=4
...
That's the information that libtermkey will need to know, which it
currently hardcodes. And now our codes are no longer set in stone, yet
we can still understand the modifiers etc...
Complications abound for the F1 to F4 keys of course:
unmodified shifted ctrled ...
F1 SS3 P CSI 1;2P CSI 1;5P
F5 (for comparison) CSI 15~ CSI 15;2~ CSI 15;5~
So maybe the entries for F1 to F4 would have to remark on this somehow.
For that matter, it might justabout be possible to backhack these out by
parsing the original key_foo strings
key_home = \E[H
so we recognise that key_home is a CSI H sequence, and add it to the
list accordingly, so we'd recognise CSI 1;2H as Shift-Home, CSI 1;3H as
Alt-Home, and so on for all the other modifier cases.
There's always cornercases though
<Tab> 0x09
<Shift-Tab> CSI Z
I don't have a neat answer to this one while remaining entirely within
the flat namespace of key=value strings that terminfo provides.
Effectively we have a n * 2^m space of strings for n function keys and m
modifiers. It's just the vast majority of that space we can
programmatically recognise. I'd rather store the n key bases and m
modifiers, than have to store all n * 2^m simple strings.
And again, see the point about graceful failover with having a
futureproof CSI parser.
--
Paul "LeoNerd" Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
