PATCH: Re: Delaying menu completion

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

martin.ebourne@xxxxxxxxxxxx wrote:

> ...
> 
> > The caveat I mentioned is that _approximate has this strange test in it:
> >     [[ "${#compstate[unambiguous]}" -ge "${#:-$PREFIX$SUFFIX}" ]]
> > That means that the unambiguous prefix must be longer than the word on
> > the command line.  I.e., there's no way to prevent it dropping into
> > menu completion unless all the matches have a common prefix longer than
> > what's on the line right now.  I don't remember what that was supposed
> > to accomplish, but it seems a rather unlikely situation.  Sven?

We had some discussion about this twice, I think.  My hope was that it 
would use normal (non-menu) completion only if there was some sensible 
unambiguous prefix.  That, based somehow on the original string.

I think I mentioned that I wasn't sure about this even when I first
wrote it... noone came up with anything better.

> I had previously discovered this and tried removing that condition but it
> still didn't work properly. However, armed with the now working match above
> I've managed to get it to do what I want. With the patch below, I can set
> insert-unambiguous to 'always' and then it never enters menu completion,
> which is exactly what I'm after.
> 
> Someone will need to check the patch because I don't fully understand
> what's going on - its a combination of cut & paste and trial & error coding
> in there. ;)

I was thinking about the same yesterday.  I just wasn't sure if we
shouldn't remove that test completely, or make a `true' value keep it
always from starting menu completion and add some other value for a -- 
probably improved -- test to use normal completion when there is a
sensible unambiguous string.

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.

> ...
> 
> But 'zle is-completing' wasn't giving the return code (although the info
> pages say it will).

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.


Bye
  Sven

-- 
Sven Wischnowsky                    wischnow@xxxxxxxxxxxxxxxxxxxxxxx