On 1/19/12 2:25 AM, Roger wrote:
>> bind -m vi-command '"ii": vi-insertion-mode'
>> bind -m vi-insert '"ii": vi-movement-mode'
>>
>>
>> Or the following should work (untested here) using $HOME/.inputrc:
>>
>> $if mode=vi
>>
>> set keymap vi-command
>> "ii": vi-insertion-mode
>>
>> set keymap vi-insert
>> "ii": vi-movement-mode
>>
>> $endif
>
>
> I've just tested the above inputrc by executing a new bash shell instance and
> the above inputrc statement works, but there is an undesirable effect when
> using it.
>
> While in insert mode, pressing the 'i' key only once causes readline to
> intercept it and not print the 'i' char to screen if only pressed once. In
> order to get the 'i' char printed, I need to immediately press any other key
> following the 'i' char/key so it is not intercepted by readline as it is not
> a
> double 'i' key (ie 'ii').
Yes. It's ambiguous at that point. Readline can't tell whether or not
you mean 'ii' until you type the second `i'. If you type something else,
you must not have meant 'ii' and readline can use the original binding
to self-insert.
Readline doesn't add characters bound to a multi-character key sequence to
the editing buffer and perform redisplay, because it will just have to go
back and erase them later in the majority of cases.
I could look at putting in some sort of inter-character timeout, but I
don't know yet how well the code structure lends itself to that.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
