I see two problems with input queue:
1. Recognition and mapping keys that currently cannot be mapped.
2. Keeping backward compatibility with old behavior: e.g. keeping <Tab> and
<C-i> the same while allowing to map them separately.
I think that these problems should have separate solutions. To solve 1. we must
solve two problems
1. Have an agreement for new escaping scheme for byte queue. I may suggest
taking some unused <80>{C1}{C2} sequence and agreeing that
<80>{C1}{C2}{CMod}{Key}<ETX> means that
1. User pressed key named {Key} which is either a key name (like Up) or a
character in &encoding with the exception that it cannot be control character.
Key name obviously must be normalized.
2. This key was pressed with modifiers {CMod} which contains a bit field:
Bit idx Meaning
7 Always 1. Does not allow byte to be zero.
6 Shift
5 Control
4 Alt
3 Win
2 Reserved (X11 definitely has something to fill it with, but I do
not know what. Super?)
1 Reserved.
0 Reserved.
// 0. <ETX> is simply an end-of-key marker.
3. Any key that can be represented with already existing <80>{C1}{C2}
sequence *must* be represented with it. Control-{latin letter} without
additional modifiers *must* be represented with control character. Latin letter
without modifiers except for shift *must* be represented as itself. And so on:
existing scheme should be kept for compatibility.
2. Second problem is pure technical: someone must sit down and code this. Maybe
use some terminal library, maybe not. The main idea of p. 1. is that we need
*no* changes if we *not* want to support new functionality (this is mainly
needed not because someone may not want, but because we may be unable to find
developers to code this functionality into specific supported GUI).
Solving top 2. (backward compatibility) issue with the above agreement on
backwards compatibility in escaping may be deferred until there is an agreement
while continuing to work on more urgent problem with not mappable sequences. As
I mostly use ,{key} mappings and not control sequences I do not have a strong
opinion on what to do with this: <Tab>=<C-i> and <Tab>≠<C-i> are both fine,
though I got used to use <Tab> for completion and <C-i> as an opposite for
<C-o> (for consistency). Do not think this will change as built-in
functionality.
If we solve top 1. solving top 2. will be much more trivial unless found
agreement will be something insane, like DWIM behavior based on statistics of
<Tab> hits after typing <C-i>.
--
--
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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
