On 18/03/11 8:38 PM, Philippe Vaucher wrote:
As long as the two triplets of keypresses I suggested originally can all
be represented uniquely, and without reference to timing information in
the Escape vs Alt+ case, then I'm happy with whatever internal
implementation makes it happen.
The two triplets in question being
<Tab>
<Ctrl-I>
<Ctrl-Shift-I>
<Escape> C
<Alt+C>
é
Yes I am aware that on current byte-driven terminals there is no way
without using timing information to distinguish all these three cases in
the latter triplet here. This should not stop GUI systems from
distinguishing them however.
Can someone (Bram?) tell us if Bram's proposed solution would allow us
to map those triplets independently as wanted?
Of course it does. Bram wouldn't have suggested it if it wouldn't work
at all....
I'm not familiar enough about vim's byte queue system to tell if the
modifier byte really answers our needs here.
I don't think we need to keep the same byte-stream representation as we
currently have, and I don't think that's what Bram meant. I think we can
change it. As long as it remains a byte-stream representation.
And I don't think it will be possible to do what we need without at
least extending it. At the moment, keys are a fixed length of 3 bytes
(one of which is the 'escape byte' 0x80, and the other two of which have
restricted values). There simply isn't enough value-space to do what we
need, and it's possibly not very future-proof even if we can squeeze it
in. It's also a bit of a mess, IIRC. It would be better to give it an
overhaul. And it probably needs to use variable-length sequences.
A thought occurred to me a couple of days ago: would it be appropriate
to actually use CSI as the byte-stream representation? Or something like
it. It is a byte-stream representation, right? And it's extensible,
right, so it is less likely to need a big overhaul in future? Does it
allow for 'private use' stuff? Because Vim needs a way to represent a
bunch of other events as keystrokes (mouse clicks, scroll wheel, its
magic script-local meta-character thing, representing the CSI escape
character itself, etc.). Also, is it easy to skip over CSI sequences if
necessary with simple logic?
I think there are some nice/helpful things that could be done
design-wise though. For example, Vim is often used with enc=utf-8 these
days. I think it would be wise to, if possible, ensure all key sequence
representations are invalid UTF-8 in their entirety. Then they could be
put in buffers and yanked back into registers without ambiguity
(hopefully), i.e. there wouldn't be the ambiguity of whether the escape
character was part of a key sequence that should be yanked as such, or
part of the buffer text which should be escaped upon yanking.
See, Vim already deals with the CSI character in its byte-stream code,
and escapes it, so some aspects of this are already somewhat accounted
for. But I wonder when precisely it is escaped, and whether at times it
is escaped when it shouldn't be, or not when it should be. It would be
good to design to avoid this problem.
(I happened to be hacking on some Vim code recently where this came into
play, so I noted it with interest.)
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
