>> 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
> 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
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.