Re: PATCH: Re: Delaying menu completion

[martin.ebourne@arcordia.com]

> So I'd have changed it to either:
>
>   if zstyle -t "..." insert-unambiguous; then
>     compstate[pattern_insert]=unambiguous
>   elif _requested ...
>
> or
>
>   zstyle -s "..." insert-unambiguous ins
>   if [[ $ins = (true|yes|on|1) ||
>         ( $ins = sometimes &&
>           $compstate[unambiguous] -is sensible ) ]]; then
>     compstate[pattern_insert]=unambiguous
>   elif _requested ...
>
> What do people think?  Should we make `always' normal the meaning of
> insert-unambiguous==true?  Keep the test?  Making it be used on a new
> special value would of course do no harm.

The problem here is this will give you what I had been getting yesterday
when playing with this. In the case that the unambiguous bit is shorter
than the word on the command line, the extraneous stuff is deleted from the
command line. This certainly isn't what I wanted (maybe someone does
though) - I just wanted it to do nothing at all, leaving me to either edit
the line or invoke menu selection. In order to get that to happen, the
following chunk of code I purloined from _match is essential:

      [[ "$compstate[insert]" != *menu ]] &&
        compstate[pattern_insert]= compstate[insert]=

> Ah.  Humm.  That's caused by completecall() (in zle_tricky.c).  The
> problem is that the completion widgets normally return non-zero if no
> matches were generated and the code there tries to ensure that even
> for user defined completion widgets.  I.e., it specifically replaces
> the zero returned from a user-defined widget with a `1' to signal that
> completion `failed'.  That's ugly in cases like this one, yes, but I
> don't know if we should change it.

Sounds like something that's better left alone to me. Presumably the
returning 1 is to get zsh to ring the bell. Perhaps a note on this in the
info pages would be the best solution.

Cheers,

Martin.