Re: [Bug-readline] Custom vi mode bindings causes problems with some builtin commands

[Chet Ramey]

On 6/22/15 6:25 PM, Carlos Pita wrote:
> Thank you very much Chet for looking into this.

It will be fixed in the next release of readline.

> Just out of curiosity, I would like to ask you about the way some
> aspects of the vi bindings work:
> 
> 1) Some commands are mapped twice: say vi-change-to is bound both to c
> and C. Does readline depends on the binding order to tell c appart
> from C? Should vi-change-to and similar commands always be mapped to
> the same key, except for the case?

The binding goes the other way: each key sequence is mapped to only one
readline command, but a readline command may be mapped to any number of
key sequences.  The key bindings for vi mode are determined by Posix
and historical convention.

> 2) Some more complex commands are mapped n times: say vi-char-search
> to t, T, f, F, ; and ,! A fortiori: does readline depends on the order
> or another internal convention to identify which "subcommand" of
> vi-char-search to invoke?

Each bindable readline command uses the same calling convention, which is
described in the readline texinfo documentation:

The calling sequence for a command @code{foo} looks like

@example
@code{int foo (int count, int key)}
@end example

@noindent
where @var{count} is the numeric argument (or 1 if defaulted) and
@var{key} is the key that invoked this function.

So readline functions that have very similar behavior and are bound to the
same top-level function, like the various permutations of char-search you
identified, use the `key' argument to distinguish between different
behaviors.  This limits the customizability of vi mode somewhat, but as the
readline documentation says, the goal of vi mode is to provide what Posix
specifies.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/