zsh-workers
 help / color / mirror / code / Atom feed
* Re: PATCH: Re: Delaying menu completion
@ 2001-08-14 12:24 martin.ebourne
  0 siblings, 0 replies; 5+ messages in thread
From: martin.ebourne @ 2001-08-14 12:24 UTC (permalink / raw)
  To: Sven Wischnowsky; +Cc: zsh-workers



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



^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: PATCH: Re: Delaying menu completion
@ 2001-08-16  9:51 martin.ebourne
  0 siblings, 0 replies; 5+ messages in thread
From: martin.ebourne @ 2001-08-16  9:51 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers



> }    _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


^ permalink raw reply	[flat|nested] 5+ messages in thread
* PATCH: Re: Delaying menu completion
@ 2001-08-14  9:21 martin.ebourne
  2001-08-14 12:02 ` Sven Wischnowsky
  2001-08-14 16:03 ` Bart Schaefer
  0 siblings, 2 replies; 5+ messages in thread
From: martin.ebourne @ 2001-08-14  9:21 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers





> 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






^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2001-08-16  9:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-14 12:24 PATCH: Re: Delaying menu completion martin.ebourne
  -- strict thread matches above, loose matches on Subject: below --
2001-08-16  9:51 martin.ebourne
2001-08-14  9:21 martin.ebourne
2001-08-14 12:02 ` Sven Wischnowsky
2001-08-14 16:03 ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).