On Sunday, October 27, 2013 6:54:16 PM UTC+4, Michael Henry wrote: > On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar <b...@moolenaar.net> 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.
Please explain how you are going to differentiate CTRL-I and Tab in random terminal emulator. Some may be configured to output either as CSI sequence, but not all. This is not simply historical artifact. Also some users (including me) are used to use Ctrl-I and Tab interchangeably. It is not much problem to restore old status if <C-i> and <Tab> started to have different meaning even without any options for backwards compatibility, thus I would not object against patch that will diversify them. I do not get though why <C-B> and <C-S-B> should ever have the same meaning though, and it is what is meant by “100% backwards compatibility”. > 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 :-) I doubt that adding some option will simplify implementation. This option (if implemented) is also much likely a candidate for resetting when 'compatible' is reset. Thus adding it at the very top is not a good idea if you have `set nocompatible` there. And it is good to have `:scriptencoding utf-8` as the very first line in the 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
