On Tue, Feb 22, 2011 at 11:43:39PM -0500, Benjamin R. Haskell wrote: > Taking that as a given, I'm going to ignore that aspect of this > issue. My question is about libtermkey. I was curious enough to > download it, unpack it, `make` it, and run ./demo. And, > surprisingly, given that it seems to be the favored example, > pressing <Tab>, then <Ctrl>+<i>, then <Ctrl>+<Shift>+<i> gave me the > output sequence: > > <Tab> > <Tab> > <Tab> > > So, I'm wondering: what does libtermkey bring to the table?
It parses CSIs, the way that xterm et.al. send modified keys. Start an old vim. Go into insert mode. Press Ctrl-Left. xterm sends CSI 1;5D Without a CSI parser, using only a 1970s-style terminfo-driven prefix hunting algorithm, there is no terminfo key sequence matching this. So vim gives up. It then sees Escape [ 1 ; 5 D. The upshot is that vim leaves insert mode (Escape), does something unimportant with [ 1 ; then deletes 5 lines of text (5D). With a CSI parser such as libtermkey, this is recognised as a real CSI D call, with the parameters 1 and 5. This is reported to the application as Left (CSI D), with the Ctrl modifier (2nd param being 5). The primary thing that libtermkey brings, is not blowing up and deleting 5 lines of your text just because xterm happened to send a valid CSI sequence that isn't in the terminfo. > I tested under both rxvt-unicode (my preferred terminal emulator) rxvt uses its own, totally-incompatible encoding scheme for modified keypresses. This scheme is different to any other terminal that has such abilities (all the others follow xterm's CSI scheme). It is also incompatible with ECMA-48 (whereas xterm extends it), inextensible beyond Ctrl and Shift, and arbitrary (happening to pick three ASCII characters seemingly at random, to represent the Shift, Ctrl and Ctrl+Shift states). > and uxterm (which, AFAIK, is a "properly-configured" xterm). If > "properly-configured" actually means "specially-configured", Specifically-configured means modifyOtherKeys: 2 Except that on its own now breaks most other applications, because xterm is too keen to use the CSI encoding scheme on "normal" keypresses, such as Ctrl-D. xterm doesn't yet send the correct and useful sequences here, but it is not difficult to fix its code to do so - I have been in occasional contact with Thomas Dickey on this issue; I need to poke him again sometime soon to check he's properly looking into it. What is needed is a hybrid scheme, whereby the simplest key encoding is used in a nicer way; where Ctrl-D would send the single 0x04 byte (so kernel's pty driver can recognise "here's an EOF"), but Ctrl-Shift-D sends CSI 68;5 u to encode it correctly. > how > would using libtermkey be anything less than a huge PITA when > working on multiple systems that aren't so configured? Or is this a > chicken-and-egg problem? (Nothing is configured to send anything > other than 70's-style "<C-i>" == "<Tab>", so nothing ever will be.) Rightnow, xterm will send the same byte for Tab, Ctrl-I or Ctrl-Shift-I. Setting modifyOtherKeys to 2 will send real keypresses that it can tell, but now everything else cannot. Ultimately, yes. It is chicken and egg, in order for -everything- to work in a happy shiney way. But even without terminal changes, applications can benefit from using libtermkey now. So to answer your question on "how would using libtermkey be anything less than a huge PITA" - it isn't. It already recognises, via its terminfo-driven parser, every keypress that terminfo/curses already recognises. It cannot be worse. It is strictly better than, because of the full CSI parser I mentioned above. Even if it cannot pass on that information to its containing program, it can at least parse it. If libtermkey was used by some application that has no concept of modifier keys, then modifiers would just be ignored; i.e. that pressing Ctrl-Left would simply be read as a Left keypress, not resulting in a beep and deleting 5 lines of text (vim), or beeping and appending ;5D to your shell prompt (readline, irssi, etc...). Furthermore it is much more future-proof. Just as in 1970 nobody considered modifier keys, right now nobody has, say, pressure-sensitive keyboards, so nobody bothers reporting pressure information. Maybe in another 20 years time we'll all have keyboards that can recognise a gentle vs. hard press of a key, or multi-touch with two fingers, or whatever. It would be quite natural to use the 3rd CSI argument, say, to encode this. Up CSI A Ctrl-Up CSI 1;5 A Forceful-Ctrl-Up CSI 1;5;3 A A terminfo-driven string prefix parser will of course blow up here. The code in libtermkey, right now today, will not blow up. It won't -understand- that 3rd parameter, it cannot -report- that to its containing application, but it will correctly parse it to ignore it - reporting to its application the press of Ctrl-A, by ignoring the Forceful part. Using libtermkey today leaves terminal developers of the future the freedom to extend the CSI parameters in whatever way they see fit, knowing that if old applications can't make use of this new information, they are not at least confused and inconvenienced by it. Hope that helps, -- Paul "LeoNerd" Evans [email protected] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
