Imap which “give up” when not matching (like vim)

[antoine9298]

I configured vimb and vim to exit insert mode when I press “aa” like this
:imap aa <Esc>
But unlike vim, vimb don’t input any a anymore…

vim
« I’ve got a computer » -> « I’ve got a computer »

vimb
« I’ve got a computer » -> « I’ve got computer » # with 2 space and no a

Not been able to type any a is not very fancy…

[fanglingsu]

Sorry for the late answer. The imap does not work like you know it from vim, and I assume it will never work like it in the near future.
According to #176 and #196 the imap or better the input mode is really simple. All keys you type are handled by gtk or webkit. Simple and straight forward. OK, there is some code that allows you to do some special things with imap, but this works only for noneprintable keys. At the time there is no really usable API in Webkit to write things into the current active form field that would be required to do the real imap stuff. And I fear we end up with bloated and buggy vimb in case we try to work around this by some JavaScript hacks. The main issue at this time is, that we can react to the current key event and decide if this is remapped or if it should be handles by webkit. To allow :imap aa <Esc> would need logik to turn some keyevent into text to print into inputfield. And this is not the whole truth, in this case vimb have to manage also the none printed action in form fields, selecting text, delete whole word in front of cursor, move cursor behind next word and so on.

[MichaelMackus]

👎

This kills vimb usage for me. IMO vimb should try to emulate vim as close as possible.

@fanglingsu Is there not any way to extend map.c to input the character in the curent queue, assuming the next key doesn't match? It looks like the logic for the map queue is already there, so from my point of view this wouldn't be too hard. I'm not sure I follow your logic in the last sentance of your comment above.

[fanglingsu]

@MichaelMackus It would be a hard way to do this. Because we don't get chars from gtk but key events. To queue chars we have to implement logic, handling input modes and knowing to much about character sets. Many char that can be entered fire multiple key events (not every user want to print ascii chars only). At the time we take the key events and convert them into some internal data structure that is queued and can be processed by vimb. And we could write some logic to generate printable chars from these queues internal structures to write them char by char into focused form field. But this would require vimb to do all the form field editing by itself (currently this is done by webkit).

[MichaelMackus]

Hmm. I'm not sure any further mapping needs to be done, though. We have the list of ascii chars in the actual "map" line. So if I do "imap jk " then we know once we match the second char (if its not "k"), the full ascii string input would be "j". This would have to be inserted somehow into the form input before the next character is input. This must be what you refer to as the main complication since I suppose we'd need more form handling in vimb in order to input a character before it gets handled by webkit?

[MichaelMackus]

@fanglingsu for example, we already store the mapped ascii character in the "Map" struct. I'm wondering if somehow we can just submit a GTK/Webkit event in map.c around line 312 with the mapped char?

Assuming we need to send GTK the actual key Event, we could just add another queue to store these events in the "map" struct, no?

[MichaelMackus]

I'm going to start a PR for this if you don't mind. I've found a few pieces of documentation that could help. I think all we need is the keycode corresponding to the key that was pressed, then simply pipe that to GTK using some code like this.

It looks like the GdkEventKey struct contains the keycode we need.

[fanglingsu]

I think the current implementation is no good basement for such a logic. We turn the gtk key events into some unsigned char codes with the known penalties (<CR> is the same like <C-M>). Some unicode chars are turned into sequence of three unsigned chars to support more key mappings. So, it's not as easy to take our mapped char and turn it into a keyevent back. Don't forget that we give char by char to the current active mode to handle it, so we have to put each none handled or possible none handled char back into a queue until we know what to do with these chars - discard or refire as new gtk key events.
If though of another approach mentioned in #247 to not turn the key events into internal unsigned chars. But I'm not sure how complicate this would be and if this would really help in the case of imap keybindings.

[MichaelMackus]

@fanglingsu I think my approach would work. I've added a PR with some basic functionality that seems to be compiling & running just fine so far. Let me know your thoughts when you find some time.