On Wed, May 05, 2010 at 10:40:39PM +0200, Bram Moolenaar wrote:
> Paul LeoNerd Evans wrote:
> > 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.Actually, I've now just remembered why I wanted to change this, why I thought a byte queue is a really bad idea. To quote #vim/Freenode just now: (18:31) <qbit_> can the esc key be compeletly disabled ? (18:31) <qbit_> I am trying to force myself to use ctrl+c (18:32) <qbit_> i tried noremap <Esc> <NOP> (18:32) <LeoNerd> I really would suggest not (18:32) <LeoNerd> eeeeeverything will break, if you do that ... (18:34) <LeoNerd> If you map <Esc> away you'll break all the arrow/function/cursor keys (18:35) <qbit_> how will that break them ? (18:35) <LeoNerd> Because of the way terminals work (18:35) <LeoNerd> E.g. the <Up> arrow key is <Esc>[A (18:35) <LeoNerd> So if you map <Esc> to something else, the Up arrow key no longer does that.. and breakage happens We -really- need to be able to distinguish Escape, the ASCII sequence of 0x1e, from <Esc>, the human-level idea of pressing that piece of plastic. This would enable us to :map <Esc> foobarsplot without affecting any of the other keypress events that start with an Escape byte, such as all the CSI and SS3s in 7bit legacy mode. libtermkey already contains all the logic for this; it will only output a KEYSYM_ESCAPE on a real Escape (by usual prefix and timing analysis), meaning vim could map that away with confidence of knowing it hadn't broken CSI/SS3-based keys. If it will further sway the argument, libtermkey even supports a "render this struct into a human-readable string" sprintf()-alike operation, allowing it to produce strings looking like <Escape> <Ctrl-Up> etc... A little further effort could create a sscanf()-alike to parse these, giving really easy integration with all of vim's mapping layer. What thoughts here - can we further consider a keypress-event-structure queue instead of raw terminal bytes? -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
