Re: Keyboard input handling
I'm interested in trying my hand at implementing this. I'm new to vim-dev, so if anyone has any advice or reading material I should review, I'd appreciate it :) -- View this message in context: http://vim.1045645.n5.nabble.com/Keyboard-input-handling-tp1211322p3322160.html Sent from the Vim - Dev mailing list archive at Nabble.com. -- 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
Re: Keyboard input handling
Hello. This is very interesting thread. 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 And also get rid of the waiting loop for distinguishing between manual Esc key press and a terminal generated sequence of bytes... BTW, slightly different topic: how can one remap some internal function from its default hotkey to the different one? As far as I know there is nothing like leave insert mode function which can be mapped to the different key in case Esc is already mapped to something else. Am I wrong? Typical example: make 'Q' working as original 'D', that part works: :map Q D now remap 'D' to something else as we have 'Q' for original 'D' action already :map D $ now both 'Q' and 'D' work as '$' instead of having 'Q' working like original 'D' and 'D' working like original '$'. Milan -- 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
Re: Keyboard input handling
On 13 May 2010 11:18, Milan Vancura mi...@ucw.cz wrote: BTW, slightly different topic: how can one remap some internal function from its default hotkey to the different one? As far as I know there is nothing like leave insert mode function which can be mapped to the different key in case Esc is already mapped to something else. Am I wrong? Typical example: make 'Q' working as original 'D', that part works: :map Q D now remap 'D' to something else as we have 'Q' for original 'D' action already :map D $ now both 'Q' and 'D' work as '$' instead of having 'Q' working like original 'D' and 'D' working like original '$'. Milan I'm not sure I get your point, but it seems that the problem you are describing is solved by using nnoremap, vnoremap, onoremap instead of map. -- Regards, Lech Lorens -- 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
Re: Keyboard input handling
On 13 May 2010 11:18, Milan Vancura mi...@ucw.cz wrote: BTW, slightly different topic: how can one remap some internal function from its default hotkey to the different one? As far as I know there is nothing like leave insert mode function which can be mapped to the different key in case Esc is already mapped to something else. Am I wrong? Typical example: make 'Q' working as original 'D', that part works: :map Q D now remap 'D' to something else as we have 'Q' for original 'D' action already :map D $ now both 'Q' and 'D' work as '$' instead of having 'Q' working like original 'D' and 'D' working like original '$'. Milan I'm not sure I get your point, but it seems that the problem you are describing is solved by using nnoremap, vnoremap, onoremap instead of map. Ah, yes, my fault. Thank you. Very non-intuitive (esp. in reverse order of mappring) but works. Milan -- 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
Re: Keyboard input handling
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 everything 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
Re: Keyboard input handling
On Wed, May 05, 2010 at 10:40:39PM +0200, Bram Moolenaar wrote: 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. ... 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. Hi Bram, Thanks for the response on this. It looks like then there's three separate issues here: 1. Making sure that the input queue really can distinguish Ctrl-T from Ctrl-Shift-T, and also between e.g. Tab and Ctrl-I 2. Getting GUI-based frontends to correctly insert input queue keypresses 3. Using libtermkey or similar, to recognise keypresses on terminals I'm actually away until Tuesday now, but when I get back I'll take a further look into things, mostly in this order. Though, I forsee there's probably scope for some parallelising between other developers, if someone else manages to make some headway into one of the bits in the meantime. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Keyboard input handling
On Tue, May 4, 2010 at 8:14 PM, Tom Sorensen wrote: On Tue, May 4, 2010 at 7:14 PM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: 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. Actually, he's understating it. We usually get at least two people a week. Several people a day isn't too uncommon. A lot of this is because vim has already used pretty much every non-shifted key on the keyboard -- you're left with either replacing default functionality (which I don't like suggesting) or using Leader based combinations (which I'm fine with, to a certain extent, but many others are not). I'd be certain that the average is at least 2 or 3 people a day - many of the IRC regulars have seen this question get asked multiple times in one day, and we're not on for 24 hours - usually more like 2 or 3. And let's not forget how often it comes up on the mailing list - A quick search over the last ~1 year shows the below list of threads that all amount to you can't map that in vim. I emphatically agree that vim's keyboard handling is one of the ugliest parts of the editor; something definitely needs to be done to bring vim back up on par with other GUI tools. ~Matt Mapping Shift-space: how to tell if its possible? How to imap C-= ? CTRL+W under MS Windows map a-h on win32 (Win XP) gvim 7.2 in french layout work incorrectly accent grave in french(France) keyboard layout is not printing. win32 (Win XP) Platform why nmapA-0 not work? map a-h on win32 (Win XP) gvim 7.2 in french layout work incorrectly What is Alt-T supposed to do by default? Mapping ctrl-; (ctrl semicolon) mapping problems How to map Ctrl+/ ? mapping alt-keys add mapping to auto-fill Binding Ctrl+Tab and Ctrl+Shift+Tab difficulties with Vim and PuTTY. Bugging me for a long time Can't :imap S-space How to map Alt+key when using vim in putty How to get Alt-[ in putty terminal How to map ctrl-del to delete word? how to map tab and c-i independently How to map key shift+ctrl+N? I can't remap Shift-F4 key Insert Mode Mappings on a Mac map! C-= C-ogt and map! C-- C-ogT Don't work map command, ctrl-v and .vimrc map C-J C-Wj not operate...help.. mapping control+0-1 or backtick Maping Ctrl-Shift-s problems Mapping shift-space Mappings to shift-keys within terminal mode Mappings for tab navigation don't work Tab and C-i will clash in mappings unable to map ctrl-1 Unable to map Ctrl+Shift+Z Strange behavior with Key Maps -- 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
Re: Keyboard input handling
On May 5, 1:14 am, Paul LeoNerd Evans leon...@leonerd.org.uk 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. [...] FWIW: I wholeheartedly support this feature, and would make myself available for implementation and testing, if someone with the ability to see it through takes the lead. Henrik -- 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
Re: Keyboard input handling
On May 4, 6:14 pm, Paul LeoNerd Evans leon...@leonerd.org.uk 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. I know next to nothing about the termcap/terminfo/etc. code or what is involved in such a change, and do not have the time currently to start delving into Vim's C code (sometime soon, I keep telling myself) but I would certainly be willing to test on Windows XP and Vista, even to the point of learning how to compile my own Vim on these systems so that I can try out the patches. I have a Ubuntu system at home but don't get many chances to use it; I image we'll have a plethora of testers on such systems though. -- 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
Re: Keyboard input handling
Original-Nachricht Datum: Wed, 5 May 2010 00:14:06 +0100 Von: Paul LeoNerd Evans leon...@leonerd.org.uk An: vim_dev@googlegroups.com Betreff: Keyboard input handling 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. [...] I could test it on Ubuntu 10.04 and Mac OS X 10.6. Would this change also handle special keys found on some keyboards? I could test with some different keyboards. HTH, Dennis Benzinger -- 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
Re: Keyboard input handling
On Wed, May 5, 2010 at 11:20 AM, Ben Fritz wrote: On May 4, 6:14 pm, Paul LeoNerd Evans leon...@leonerd.org.uk 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. I know next to nothing about the termcap/terminfo/etc. code or what is involved in such a change, and do not have the time currently to start delving into Vim's C code (sometime soon, I keep telling myself) but I would certainly be willing to test on Windows XP and Vista, even to the point of learning how to compile my own Vim on these systems so that I can try out the patches. I have a Ubuntu system at home but don't get many chances to use it; I image we'll have a plethora of testers on such systems though. I've got access to xterm on HP-UX, AIX, and Solaris 9 and 10 - nothing too exotic, but I can help test there - and in Linux with fbiterm, which is pretty exotic as far as terminal emulators go these days. ~Matt -- 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
Re: Keyboard input handling
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
Keyboard input handling
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.
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.
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/
-
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: Keyboard input handling
On Tue, May 4, 2010 at 7:14 PM, Paul LeoNerd Evans leon...@leonerd.org.uk wrote: 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. Actually, he's understating it. We usually get at least two people a week. Several people a day isn't too uncommon. A lot of this is because vim has already used pretty much every non-shifted key on the keyboard -- you're left with either replacing default functionality (which I don't like suggesting) or using Leader based combinations (which I'm fine with, to a certain extent, but many others are not). *: 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. Paul knows his stuff when it comes to terminal encoding. He's one of the only people who *really* understands termcap/terminfo that I know, as well as xterm and EMCA standards. And he's stated on #vim that libtermkey is backwards compatible in that it will read terminfo files and handle anything in the terminfo database correctly. The API is different, but that's because it has to be -- it's exposing far more functionality than termcap/terminfo could ever dream of. Historically, termcap and terminfo date back to code that was originally in vi. I think it would be appropriate if the next improvement in terminal key handling came, in large part, from the vim community. It would be a great feature for v8. And I'm quite sure there would be plenty of beta testers on numerous platforms (I'll personally volunteer for XP, AIX 5.3, Solaris 9, RHEL5, and RHEL6). Tom -- 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
