Paul LeoNerd Evans wrote:
> Vim's keyboard input system revolves centrally around a queue of bytes.
> This worked well when all the world was serial terminals. In this new
> world of GUIs this model doesn't work so well. I advocate changing it to
> a queue of keypress events.
>
> Over the past 7 years, I have been a member of the #vim channel on
> Freenode. Almost every week we get somebody in the channel who wonders
> such things as how to map Ctrl-Shift-T differently from Ctrl-T. We
> explain that isn't possible. Even in Gvim. Because of vim's input queue
> system. People often don't realise that Tab is Ctrl-I, or Enter is
> Ctrl-M. We have to explain why it's not possible to map one of these
> pairs without breaking the other. It's become apparent to me that the
> byte-based model is no longer appropriate if Vim is to remain relevant
> and current on newer platforms. It's time we changed the core.
That's not completely correct. Vim can have a key modifier in the
queue, it can have CTRL and SHIFT before a T. It's a design choice to
have CTRL-SHIFT-T and CTRL-T result in the same code. See the global
variable "mod_mask".
It's possible to make a difference between the two when there is a
mapping for CTRL-SHIFT-T. I actually thought that was working, but it
doesn't. Perhaps this only works in combination with Alt, don't have
time right now to check the details.
> I would like to propose that the base of the input queue be turned into
> a queue of structures something like the following form:
>
> struct keypress {
> enum {
> UNICODE,
> SPECIAL,
> } type;
> int keycode;
> int modifiers;
> };
>
> In this scheme we can represent any of the keypresses vim can handle:
>
> A = { .type = UNICODE, keycode = 'A', .modifiers = 0 }
> <Ctrl-T> = { .type = UNICODE, keycode = 'T', .modifiers = CTRL }
> <Enter> = { .type = SPECIAL, keycode = ENTER, .modifiers = 0 }
>
> In this scheme, it is simple to write the code that :map etc.. will use
> to recognise the keys and turn them into basic operations. It's also
> simple to generate these events from GUI events (such as from GTK or
> Win32).
>
> This scheme is also relatively simple to generate from terminal input
> bytes, since vim already has this functionality.
>
> Once using this scheme, gvim would now fully support mapping Tab, Ctrl-I
> and Ctrl-Shift-I as three separate independent keys. Newer terminals
> like xterm already posess ways to encode these three keystrokes
> differently at the byte level, and with e.g. libtermkey[*]'s help, vim
> could be taught how to recognise all these three too.
I think this is possible without changing the input queue.
> In recognition of the non-trivial amount of work required here, and as a
> token of my commitment to this issue, I would be happy to donate a
> further EUR100 to the vim development sponsorship on top of the EUR20 I
> have just sent, if we could come to a mutual agreement on how to proceed
> on this front. It would be great if we would be able to make this
> feature a reality; I would be happy to consider a further donation at
> that point.
>
> I know this isn't the way terminals have worked for the past 20 years.
> However, it is the way "terminals", being the units of end-user
> interaction, will work for the next 20 years. It would be nice if vim
> were able to cope as well with the next 20 as it has with the last.
>
> -----
> *: I have also been developing a library, libtermkey, which aims to be
> a better way to read key press events from terminals than existing
> solutions that are curses or terminfo-based. While it reads the
> terminfo database, it also fully understands the extended ways that
> xterm et.al. encode modified keypresses, in a way that would be
> fully compatible with vim's core, and existing behaviours.
>
> http://www.leonerd.org.uk/code/libtermkey/
Now that sounds like a long awaited improvement. The termcap/terminfo
system is completely inadequate. Vim must have xterm special key
support built-in, since there is no way to define these keys with the
old libraries.
It would be great if someone can make a patch for Vim that uses this
library and is fully backwards compatible for the special xterm keys
codes. That would be a good test for the library as well.
--
hundred-and-one symptoms of being an internet addict:
23. You can't call your mother...she doesn't have a modem.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.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
