On 10/28/2013 07:41 AM, Bram Moolenaar wrote:
>
> Michael Henry wrote:
>> So I suggest that a single global option that simply switches on
>> support for extended modifier for all keys, regardless whether
>> those keys are mapped, may well be good enough and might make
>> the implementation simple enough to become reality. The day the
>> option appears in Vim, I'll put it at the top of my .vimrc :-)
>
> So we add an option that breaks mappings? No, not a good plan.
Sorry I was not clear. I certainly wasn't trying to break all
mappings :-) I was thinking of and discussing mostly the :map
functionality of Vim, not (yet) the terminal-handling side, and
talking about behavior for a terminal where the codes for <Tab>
key and <C-I> are distinguishable.
Also, I'm not familiar with all the inner workings of Vim, so
the suggestions below might be laughable to those with better
understanding. So I thought I'd try to clarify it some more.
Worst-case, I figure at least you'll get a laugh :-)
Today, users that have both :map <Tab> and :map <C-I> will find
that the most recently defined map clobbers the other, because
Vim aliases them even in the definition of the mappings. I'd
like to see Vim eliminate the enforced aliasing at this layer
(the :map layer) for several reasons.
I think new users do not find this aliasing intuitive. There is
no intuitive reason why pressing CTRL-I should be the same thing
as pressing Tab, unless you have a priori knowledge of terminal
history.
If a terminal has a separate Tab key with a key code that is
distinguishable from the key code for CTRL-I, I'd like those
keys to remain distinguishable as Vim processes them. As much
as possible, I'd like each key on my keyboard to be uniquely
recognizable to Vim, so that I get maximum value out of these
keys. Personally, I don't get any benefit from the fact that
the Tab key is just another way of pressing CTRL-I. Though
people have found a way to get some benefit out of this aliasing
that is forced upon us by many current terminals, it seems like
a mis-feature for Vim to force it as well. Users that want two
keys to be aliases can give them identical mappings. But users
that want to treat them separately can't do it as long as Vim
aliases them under the hood.
A terminal that sends identical key codes for different key
presses is not as flexible as one that sends unique codes. We
have to deal with terminals as they exist today, which means we
have to handle hardware aliasing of Tab and CTRL-I (for
example). What if Vim were to handle this in the early stages
of terminal input, by decoding a given key code into a set of
keys aliases specific to the terminal's capabilities? So for
this particular terminal, ASCII code 9 would be translated to
the set {<Tab>, <C-I>}. Mappings would match if the mapping's
key is in the set of aliases returned from the terminal layer.
So if the user has mapped only one of <Tab> and <C-I>, Vim will
use that mapping. Vim might search mappings in reverse order of
definition so that a more recent mapping will win out in the
event of a tie. That way, a user can control on a per-mapping
basis which alias will win out in a given mapping mode.
I hope that the suggested changes above would be transparent to
most users, but there would be ways that users could detect
things were different (for example, by setting a mapping for
<C-I> and trying to query that same mapping using <Tab>). I
don't see a way to make it 100% transparent without leaving some
vestige of baked-in aliasing, which I feel should ideally be
removed everywhere except in the early terminal-handling stages;
that way, when we get terminals without inherent aliasing, we
can be rid of the aliasing problem entirely.
So the purpose of the option I was proposing was to
control whether Vim would continue to alias certain key
combinations at the point of mapping.
> It's already implemented that a key-with-modifiers that is not
> mapped falls back to the key-without-modifiers. There is no
> reason to make it more complicated for the user who hasn't
> read all the documentation of all options (hint: nobody has).
It's interesting that Vim treats a key-with-modifiers that has
no mapping as that same key without modifiers. I'm not sure I
understand how that works, nor why it's considered desirable. I
especially don't see how having that fall-back makes things less
complicated for users that haven't read the documentation. In
my way of thinking, the intuitive behavior for a keyboard is
that two different keys generally perform two different
behaviors (unless they are labeled the same, such as the two
Enter keys on a typical PC keyboard).
If Vim were changed to distinguish key names like <Tab> and
<C-I> throughout most of the code base, and to deal with
terminals that do not have unique key codes by return a set of
aliases for a given key press, I suspect that most users would
not notice any negative effects. If that level of compatibility
were good enough, then we wouldn't need any user-facing option.
My suggestion for an option was only to provide 100%
compatibility for users that want to keep the baked-in
assumption that Tab and CTRL-I (for example) are permanently
identical keys.
Michael Henry
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
