On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar <[email protected]> wrote: > I already said this: It's fine to add so long as it's 100% backwards > compatible. That means encoding keys on top of what's already there, > and falling back to the ordinary key if the key + modifier isn't mapped.
This is very encouraging to me. I read this as 100% compatibility out-of-the-box, which is a fine (and longstanding) goal for Vim. I'd be happy to have a Vim option to control this feature. It could default to providing 100% compatible key processing. If the user changes this option, he would get clean support for key modifiers with some slight backward incompatibilities. For example, the aliasing of control keys (e.g., CTRL-I being equivalent to <Tab>) is a historical artifact that I suspect has no value to the vast majority of users. If there were no compatibility concern and it's weren't *already* true that CTRL-I aliases <Tab>, would anyone seriously argue that we ought to *add* that feature to Vim? I suspect not. To me, that's a convincing argument to do the simplest possible kind of backward compatibility, since very few users actually need the old behavior. 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 :-) 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
