> This is my first time joining a discussion, I had a hard time just to
> open an account and send my suggestion. I use the default reply
> function and I don't mean to upset anyone. Hopefull now this reply is
> well-edited (I removed the quote).
>
> About vim, I misunderstood that it was a keyboard problem. As Bram
> said it is internally set as <CTRL-I> = <Tab> and people requesting
> having structured input mechanism, all I can think of is to break
> apart all internal linkages and revert to the their original settings:
>
> I found that <CTRL-M> and <Enter> both have the same keymap code 0x0d,
> and both <Tab> and <CTRL-I> gives 0x09, maybe that is why vim gives
> the same output.
[...]
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.
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". This will break existing
stuff and make users pull their hair out because they don't know this
setting exists. Forget it.
- 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.
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.
When this new modifier is not mapped, it is discarded and the following
translated codes are used normally, just like now. Thus without any
mappings that use the new modifier it is guaranteed to work as before.
When executing a register where the new modifiers are missing it works
just like before.
When a new modifier is mapped, it is replaced by what it's mapped to, AND
the following old style byte sequence is consumed.
An alternative is to let the termcap handling translate the new modifer
into the old style key. That works because mappings are applied both to
the raw escape sequences and on the key codes they are converted to.
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>
--
Not too long ago, compress was something you did to garbage...
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
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
