On Wed, 23 Feb 2011, Paul LeoNerd Evans wrote:
On Tue, Feb 22, 2011 at 11:43:39PM -0500, Benjamin R. Haskell wrote:
[...] I'm wondering: what does libtermkey bring to the table?
It parses CSIs, [...]
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. [...]
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).
The whole situation is pretty arbitrary. E.g. ./demo's output under a
modifyOtherKeys:2 UXTerm, compressed to one row, for <Shift>+ the top
row of my typical US 105-key or variant:
<S-~> ! <S-@> # $ % <S-^> & * ( ) <S-_> + <Backspace>
Why the Shift modifier on ~, @, ^, and _, but not !, #, $, etc?
(Guessing hysterical raisins.)
Didn't realize ECMA-48 existed, though. Thanks.
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.
Cool. Works as advertised (i.e. currently not in anything other than
the `demo` program, but still interesting to see the ability is built
in).
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 do <Tab> and <Ctrl-i> fit into this scheme? What's the "simplest
key encoding"?
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.
Thanks. This paragraph combined with the first section about parsing
unknown CSI sequences is plenty convincing. (trimmed rest)
--
Best,
Ben
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
