On Fri, Feb 25, 2011 at 02:43:23PM +0100, Bram Moolenaar 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.
That's OK. For them it can be mapped. Or even made default. > 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. Changing terminal emulators is a done task; xterm has supported this since 2008. In fact I asked Thomas Dickey to clarify this for me, and he informs me it's all present and working. > 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. > > Some things that are no acceptable: > - Have a setting to enable "the new way". Really? Is that what we'd have said right back at the beginning of Vim? On the subject of the 'compatible setting: "Adding a setting to enable all the vim-incompatible changes, is too complex for users to handle." > This will break existing > stuff and make users pull their hair out because they don't know this > setting exists. Forget it. Right now we have users _all the time_ pulling their hair out _because_ such a setting does not exist. Including myself. I would much rather have to support hoards of confused users in #vim by saying to them "Yes, sorry your vim can't recognise that keypress now, but set this setting and then it will" instead of "No, sorry your vim cannot recognise that keypress at all" If you would prefer to support people by telling them it is not possible, rather than telling them how to make it possible, please come to #vim and explain that to them. Every week. > - 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. OK, well that's fair. It was intended as an implementation detail in any case. I hadn't realised it would be possible with the existing byte queue. As long as the two triplets of keypresses I suggested originally can all be represented uniquely, and without reference to timing information in the Escape vs Alt+ case, then I'm happy with whatever internal implementation makes it happen. > What we can do is extend the existing modifier byte sequence. <snip long description> That all sounds a bit long and complicated, and I'm not sure I see whether it's necessarily any easier to implement than the arguably much-neater and more forward-compatible queue-of-structures idea I had originally. But again, that's all internal implementation details - whatever makes it work, I'm happy with. > We also need a way to specify mappings with the new modifier, perhaps > using a special modifier X, thus you could do: > :map <X-C-[> :echo CTRL-[<CR> > :map <X-C-I> :echo CTRL-I<CR> X for "eXtended"? Could work, though would be useful to check that doesn't collide with any named modifiers on any existing system. Perhaps some non-letter punctuation symbol? Though nothing suitable comes to mind. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
