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.