PATCH: Re: Delaying menu completion

PATCH: Re: Delaying menu completion

[martin.ebourne]

> On Aug 13,  6:53pm, martin.ebourne@arcordia.com wrote:
> } Problem 1
>    zstyle ':completion::match:*' insert-unambiguous pattern
>    zstyle ':completion::approximate*:*' insert-unambiguous yes
>

I had previously tried all sorts of things including (I thought) the above,
but I mostly concentrated on _approximate (since normally you at least
expect match to happen - if set to match-original only, at least).

It turns out that the match line above is exactly what I want, so that's
good. However for approximate there's...

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

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

Whether 'always' is the best choice I also leave to someone else. Perhaps
'only' may make more sense.

> } Problem 2
> Unfortunately $compstate[old_list] is not available until after you
> enter one of the completion widgets, so you're going to need a helper
> function of some kind, that will be used as the non-menu completion
> widget, and that sets a global variable that can be tested in place
> of $compstate when you invoke _menu_or_down.

Ah, yes, that's what I needed. Given this I tried:

   _is_completing() {
     [[ $compstate[old_list] == shown ]]
   }

   _menu_or_down() {
     if zle is-completing
     then
       zle menu-complete
     else
       zle .history-beginning-search-forward
     fi
   }

   zle -C is-completing complete-word _is_completing
   zle -N menu-or-down _menu_or_down

   bindkey "^[[B" menu-or-down
But 'zle is-completing' wasn't giving the return code (although the info
pages say it will). Given that you already mention the global variable I
guess you may be aware of a caveat for this with completion widgets.
Anyhow, this modification does what I want:

   _is_completing() {
     [[ $compstate[old_list] == shown ]] && _completing=1
   }

   _menu_or_down() {
     integer _completing=0
     zle is-completing
     if (( _completing ))
     then
       zle menu-complete
     else
       zle .history-beginning-search-forward
     fi
   }

Thanks for the help Bart... Things are working just right now and I like it
already.

Cheers,

Martin.


--- Completion/Base/Completer/_approximate.orig    Thu Jun 28 17:06:51 2001
+++ Completion/Base/Completer/_approximate    Tue Aug 14 10:02:17 2001
@@ -10,7 +10,7 @@

 [[ _matcher_num -gt 1 || "${#:-$PREFIX$SUFFIX}" -le 1 ]] && return 1

-local _comp_correct _correct_expl comax cfgacc match
+local _comp_correct _correct_expl comax cfgacc match ins
 local oldcontext="${curcontext}" opm="$compstate[pattern_match]"

 if [[ "$1" = -a* ]]; then
@@ -74,9 +74,17 @@
                "e:$_comp_correct" "o:$PREFIX$SUFFIX"

   if _complete; then
-    if zstyle -t ":completion:${curcontext}:" insert-unambiguous &&
-       [[ "${#compstate[unambiguous]}" -ge "${#:-$PREFIX$SUFFIX}" ]]; then
+    zstyle -s ":completion:${curcontext}:" insert-unambiguous ins
+
+    if [[ "$ins" = (true|yes|on|1|always) &&
+          "${#compstate[unambiguous]}" -ge "${#:-$PREFIX$SUFFIX}" ]]; then
       compstate[pattern_insert]=unambiguous
+    elif [[ "$ins" == always ]]; then
+      [[ "$_old_match_string" = "$PREFIX$SUFFIX$HISTNO" &&
+      "$compstate[insert]" = automenu-unambiguous ]] &&
+       compstate[insert]=automenu
+      [[ "$compstate[insert]" != *menu ]] &&
+       compstate[pattern_insert]= compstate[insert]=
     elif _requested original &&
          { [[ compstate[nmatches] -gt 1 ]] ||
            zstyle -t ":completion:${curcontext}:" original }; then

PATCH: Re: Delaying menu completion

[Sven Wischnowsky]

martin.ebourne@arcordia.com 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@informatik.hu-berlin.de

Re: PATCH: Re: Delaying menu completion

[Bart Schaefer]

On Aug 14, 10:21am, martin.ebourne@arcordia.com wrote:
}
} 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. ;)

You don't want this line:

} +      [[ "$_old_match_string" = "$PREFIX$SUFFIX$HISTNO" &&

The _old_match_string variable is used only by the _match completer.
If you were to try using _approximate without _match, it would stop
working.  If you want this behavior, you should change the name to
_old_approx_string and also copy the code from _match that sets it.

} > } Problem 2
} > Unfortunately $compstate[old_list] is not available until after you
} > enter one of the completion widgets, so you're going to need a helper
} > function of some kind, that will be used as the non-menu completion
} > widget, and that sets a global variable that can be tested in place
} > of $compstate when you invoke _menu_or_down.
} 
} Ah, yes, that's what I needed.  [...]
} 
}    _is_completing() {
}      [[ $compstate[old_list] == shown ]] && _completing=1
}    }
}    zle -C is-completing complete-word _is_completing

I'd suggest

   _is_completing() {
     _completing=$compstate[old_list]
   }

That way you can differentiate "yes" and "shown" in case you don't have
autolist set, or are using bashautolist.

Also, I'm not entirely certain, but you may need/want to make it

   _is_completing() {
     _completing=$compstate[old_list]
     compstate[old_list]=keep
   }

The end result is probably the same, but keeping the old list will mean
that `zle menu-complete' doesn't have to recompute it.  (I'm actually
not entirely sure what happens to the list when you invoke a completion
widget from another zle widget, but the doc implies it'll be cleared
when the completion widget finishes if old_list is not keep.)

Also, setting old_list to keep causes the widget to correctly propagate
its exit status, should you end up wanting to test `if zle is-completing'
again at some point.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Re: Delaying menu completion

[martin.ebourne]

> }    _is_completing() {
> }      [[ $compstate[old_list] == shown ]] && _completing=1
> }    }
> }    zle -C is-completing complete-word _is_completing
>
> I'd suggest
>    _is_completing() {
>      _completing=$compstate[old_list]
>      compstate[old_list]=keep
>    }
>
> The end result is probably the same, but keeping the old list will mean
> that `zle menu-complete' doesn't have to recompute it.  (I'm actually
> not entirely sure what happens to the list when you invoke a completion
> widget from another zle widget, but the doc implies it'll be cleared
> when the completion widget finishes if old_list is not keep.)

That would all seem to tie in with what I've observed. Certainly making the
change you suggested stopped the list from being redrawn.

> Also, setting old_list to keep causes the widget to correctly propagate
> its exit status, should you end up wanting to test `if zle is-completing'
> again at some point.

This bit didn't seem to work, but it doesn't matter anyhow.

Cheers,

Martin

Re: PATCH: Re: Delaying menu completion

[martin.ebourne]

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