Ok, I am resurrecting a very old thread here because it keeps coming up time and time again on #vim in Freenode, and Paul still wants this to happen, as do many of us.
On Fri, Feb 25, 2011 at 8:43 AM, Bram Moolenaar <[email protected]> wrote: > > > So the problem is that many users expect CTRL-M to have the same effect > as Enter, just like people use CTRL-[ instead of Esc. And a few people > would make the CTRL-M act different from Enter, and CTRL-[ different > from Esc. > > First problem is to actually detect what key was pressed, in most > terminal emulators this is not possible. In the GUI we can. Changing > terminal emulators to support this and making this work with Vim is a > separate issue, I'll not go into that here. Actually, that's exactly the issue that is being addressed. Vim shouldn't have to address it -- in theory termcap/terminfo were supposed to do this, but they didn't really do so well. Which is why we now have difficulty telling the difference between <ESC>o and <A-o>, as well as things like <ESC> vs <C-[>. Ultimately the proposal is that we let the raw keyboard input (for terminals) be handled by libtermkey, and it figures out if what was pressed was <ESC> or <c-[> or <C-[>o vs <ESC>o vs <A-o>. It then passes a stream of information to vim, which vim interprets properly. And yes, by default there would be a mapping (either explicit or pseudo-builtin) that treats <ESC> and <C-[> as the same, but that can then be changed by the user, just as they can now with any other mapping. > Then we need a way to make the extra information available to be used in > mappings, without breaking it for users relying on the current way. The only breakage I can foresee is if someone actually does a :map <c-i> foo instead of :map <Tab> foo -- then, yes, you'd end up with different behavior. I think this is within the realm of acceptable change, particularly if it's clearly stated in the release notes (and yes, I think this is a Vim 8 thing). > Some things that are no acceptable: > - Have a setting to enable "the new way". This will break existing > stuff and make users pull their hair out because they don't know this > setting exists. Forget it. I actually agree -- it should be just the way things work. And if it's done right then it won't break anything (beyond the above). > - Change the input queue from a stream of bytes to some list of structs. > This isn't adding any functionality and breaks all kinds of mapping > and termcode handling, register execution, etc. Forget it. The termcode handling will be replaced by this, so that's not an issue. Mapping is also not an issue beyond the above. Registers are more of an issue. No doubt. Can we think on this to come up with a solution? Perhaps the register needs to become more like a :map, with special keys expressed specially? Otherwise I think we're stuck since you cannot differentiate between <ESC> and <c-[>, and there's no way to express things like <c-space>. > What we can do is extend the existing modifier byte sequence. This is a > bit tricky, but it should work. So we add a new byte sequence with the > raw key encoded, plus modifiers. Thus for CTRL-[ you get the [ key with > the CTRL modifier. Which is precisely what libtermkey emits, and how it can differentiate between ctrl-[ and alt-ctrl-[, etc. Really what happens is that the terminal input buffer starts to look a great deal more like events that the GUI versions get. Instead of <ESC>o you get "o with alt depressed". To be very clear -- some of this will depend on a terminal with the proper support being used. But anything that's built on libvterm already has that, as well as xterm. But if you don't have those then moving to this new scheme should not break ANYTHING. Your term would still send <ESC>o and libtermkey would tell vim it saw <o with alt>. But if you do have a terminal with the right support, or you're using the GUI... well, to quote a bit from :help design-multi-platform, "Support all the keys on the keyboard for mapping." It would be great to get closer to that. Tom Sorensen -- 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
