Q1. Need to change the input queue structure?
A1. Changing this requires many other changes, and it's not clear that
there's a whole lot to be gained for doing (very) much work. The
current queue isn't so terrible, it's just not a nicely-packaged
struct.
Q2. Can current queue structure encode everything we want to encode?
A2. Sounded like a tentative "yes"[1].
It definitely needs some amount of redesign. How much is strictly
necessary, I'm not sure, but it seems to me it would benefit from more
consistency even if not strictly necessary, so changing the internal
representation to CSI or something very similar, could be worthwhile.
What it doesn't need, and really can't have, for reasons of efficiency,
is actually changing to use 16 or 32-bit 'characters' or structs. It
must remain a byte-stream representation.
Q3. Backwards compatibility - can we change the way keys are
specified, either through (i) a special modifier key? (ii) an option?
A3. (i) Sounds like a horrible idea to me, but no one responded when I
asked about it[2]. (ii) Sounded like a definite "no"[3], which seems
unreasonable to me (see same response-less email).
Personally, A3 seems like a showstopper. Fixing this set of
hysterical-raisin C-x = ASCII control character and all the related
key-mapping disabilities seems like a clear case of *desirable*
breakage of backwards compatibility.
Yeah, this might be worth further discussion/campaigning/diplomacy. My
initial thoughts in my previous email took an approach similar to the
'special modifier key' approach, but was actually an 'alternative
<>-notation' approach. I'm not sure if it's good enough, but maybe it
will be a suitable compromise. Maybe it is a bit better if current
<>-notation is considered specific if it couldn't be detected before at
all, e.g. <C-S-M> could not be detected at all, so could be considered
specific, but <C-M> and <Enter> must be considered ambiguous. Not sure.
I found your post [2] quite confusing, I'm afraid. Perhaps see what you
think of my ideas in my previous post and respond to those, and/or see
if you can do a simplified version of your thoughts in [2] that might be
a bit easier for us to digest and respond to?
If A3's not a showstopper, though, maybe the best next step would be
to start a test suite, to ensure things are working the way they're
supposed to work. Plus it gives a spec to shoot for. Things to include
would definitely be these sets:
<Tab> <Ctrl-I> <Ctrl-Shift-I> ^I
<C-m> <Enter> ^M
<C-[> <Esc> ^[
<M-i> <é>
<Alt-d> <Escape-d>
Not a bad idea. Also specification of how all of these should behave/be
represented in buffers, registers, input queue, etc. would be worthwhile.
It'd need to include those sets both as entered literally and in key
notation in the various places in which they could appear. Ben Schmidt
laid out several of those places in his response[4].
Actually, the specific paragraph you referenced in [4] is not a good
one. That was part of an argument I was building against a specific
proposal that would've really messed things up which I think we have got
past now. A better list can be found in the same post, the paragraph
beginning "This would be easier".
Smiles,
Ben.
[1]
http://groups.google.com/group/vim_dev/browse_thread/thread/d9ba7d51d7d9eb73/dd1ebb0f65445322#dd1ebb0f65445322
[2]
http://groups.google.com/group/vim_dev/browse_thread/thread/d9ba7d51d7d9eb73/0eb955217669f6bb#0eb955217669f6bb
[3]
http://groups.google.com/group/vim_dev/browse_thread/thread/d9ba7d51d7d9eb73/e05cf3068cfce300#e05cf3068cfce300
("Some things that are no[t] acceptable: - Have a setting to enable 'the new way'")
[4]
http://groups.google.com/group/vim_dev/browse_thread/thread/d9ba7d51d7d9eb73/39ebcaf32a84f1b0#39ebcaf32a84f1b0
(ś starting: "So this [ed: a new struct-based input queue] would be a
backwards-incompatible change.")
--
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
