On Sun, Feb 24, 2008 at 7:13 PM, Tony Mechelynckwrote: > > Matt Wozniski wrote: > > If anyone remembers this thread, the OP complained that he could > > neither get <s-space> to be recognized independently of <space> in vim > > nor in a GTK2 or Gnome2 gvim. I gave him a solution to get it to work > > in vim in at least one terminal (xterm, the best terminal ;) ), but > > noted that he was right - I could map it in vim after that trick, but > > not in gvim. Now that I got some time to dig around and figure out > > why, I came to the conclusion that <s-space> is completely un-mappable > > if we compiled using GTK2 and XIM. The reason is simple: we use XIM > > to translate a keypress into a sequence of UTF-8 bytes wherever > > appropriate. So, if <space> is pressed, XIM says "this key > > corresponds to ASCII 0x20 -> UTF-8 0x20", and tells us to insert 0x20 > > into our input buffer. If <s-space> is pressed, XIM says "This key > > corresponds to ASCII 0x20 (even though it's shift-modified)", and > > tells us to insert 0x20 into our input buffer. After XIM tells us > > that it handled the key press for us, we lose the information about > > what modifiers were pressed, and only have the characters that they > > correspond to. As far as I can tell, this is where <space> is a > > special case: it seems to be the only key on the keyboard that both > > corresponds directly to a character to display and corresponds to the > > same character when shift-modified. The alpha-numerics correspond to > > different characters when shifted, the function keys don't correspond > > to characters at all, nor do tab, backspace, home, end, delete, etc... > > So, the only key that would seem to need special casing is <s-space>. > > > Ctrl-a to Ctrl-z are also the same if you press the Shift key together with > them. But they aren't "single" keys. Maybe also Esc and/or Enter.
Perhaps I misphrased the distinction. It's not exactly that it "corresponds directly to a character", it's that the GTK2 XIM considers it to be "just a character", and that it can handle it on its own. Key presses like <esc>, <enter>, <tab>, <c-a>, etc, aren't considered "just a character" for this purpose; the XIM ignores them so that the application can handle them as it chooses. <space> and <s-space>, however, are both considered to be "just a space". > Shift-space is mentioned in an example under ":help 'imactivatekey'" as... > the > key combo which must be sent to the IM to activate it. (This option is not > used to change the setting in the IM, it only _tells_ vim what setting the IM > uses.) > > But I guess if your IM sends it as 0x20 is must be using something else (if > anything) as its "activate key". The GTK2 XIM doesn't use an "activate key"; instead it filters all keypresses and either tells vim that the keypress was handled (and tells vim what characters to insert into the input buffer), or it tells vim that it doesn't know how to handle the key and lets vim figure it out on its own. So, if it sees a <tab> keypress, it tells vim that it doesn't know how to handle it, and vim processes tab on its own. If it sees a <space> key press, it tells vim that it has handled it, and then tells vim to insert a " " into the input buffer. If it sees a <s-space> keypress, it does the same thing - and that's where the problem lies. In most applications, you would expect <space> and <s-space> to both just insert a " " into the buffer, but we need to do more work for key mappings. ~Matt --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
