Re: Completion quirks

Re: Completion quirks

[Zefram]

-----BEGIN PGP SIGNED MESSAGE-----

I wrote:
>With hzoli10 I got this behaviour, and also with my own patched beta10
>(though starting with the correct match).  This problem is almost
>certainly a result of my completion list patches (which I can't test
>with every option, though I did give it a bit of a work out).  Plain
>beta10 for me misbehaved on the second completion, much in the way you
>describe, so I think it is safe to say that REC_EXACT is, for the
>moment, broken.  I'll see what I can do...

The patch below fixes both of the observed problems with REC_EXACT (one
of which was present in beta10 and probably earlier betas too).  The
problem of the completion prefix being inserted a second time was due
to a missing invalidatelist(), just like the previous case of this
problem (that Zoltan pointed out).  A quick grep for do_single
indicates that all calls to do_single() that should be followed by an
invalidatelist() now are.  The older problem is due to listambig being
set, and remaining set, when REC_EXACT is invoked, letting AUTO_MENU
start menu completion on the next tab when it shouldn't.  This is fixed
by moving the line that sets listambig.

 -zefram

      *** Src/zle_tricky.c.old	Sat Jul 15 03:40:02 1995
      --- Src/zle_tricky.c	Sat Jul 15 03:47:19 1995
      ***************
      *** 3187,3193 ****
        {
            int p = (usemenu || ispattern), atend = (cs == we);
        
      -     lastambig = 1;
            menucmp = 0;
        
            /* If we have to insert the first match, call do_single(). */
      --- 3187,3192 ----
      ***************
      *** 3194,3200 ****
      --- 3193,3201 ----
            if (shortest && shortl == 0 && isset(RECEXACT) &&
        	(usemenu == 0 || unset(AUTOMENU))) {
        	do_single(shortest);
      + 	invalidatelist();
            } else {
      + 	lastambig = 1;
        	if (p)
        	    /* Otherwise we have to do menu-completion... */
        	    do_ambig_menu();

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQBVAgUBMAcusmWJ8JfKi+e9AQGUpgH/d7kksV5LZ9LB3hCleFHVSPeDxzYQ8v08
Jx+xAYQs4r5QlhQeqxWL26bJyaeofm6+8PeS+M0/JkuUw8HM5ra/Ww==
=njj8
-----END PGP SIGNATURE-----

Re: Completion quirks

[Wayne Davison]

> The patch below fixes both of the observed problems with REC_EXACT (one
> of which was present in beta10 and probably earlier betas too).

Much appreciated!  I still observe the wrong "exact" match being appended
when REC_EXACT is set without any menu completion options, but all the
other problems have been solved.  This remaining problem turns out to be
some missing braces on one of the last ifs in domatch().  This problem is
not in the stock beta10 since that if used to have just one statement (it
used commas to do multiple assignments).  I've appended a patch.

Also, thanks for pointing out what rec_exact does -- I've turned it
off.  It was an option I blindly snagged from the example zshrc that
comes with zsh -- perhaps it should be removed to make it less
confusing for new zsh users?

..wayne..
---8<------8<------8<------8<---cut here--->8------>8------>8------>8---
Index: zle_tricky.c
@@ -1462,12 +1462,13 @@
 	*fm = t;
 	*sp = 100000;
     }
-    if (!ispattern && (sl = strlen(t)) < *sp)
+    if (!ispattern && (sl = strlen(t)) < *sp) {
 	*sp = sl;
 	if (l == fmatches)
 	    fshortest = t;
 	else
 	    shortest = t;
+    }
     if (sav)
 	*e = sav;
 }
---8<------8<------8<------8<---cut here--->8------>8------>8------>8---

Re: Completion quirks

[Zoltan Hidvegi]

> Much appreciated!  I still observe the wrong "exact" match being appended
> when REC_EXACT is set without any menu completion options, but all the
> other problems have been solved.  This remaining problem turns out to be
> some missing braces on one of the last ifs in domatch().  This problem is
> not in the stock beta10 since that if used to have just one statement (it
> used commas to do multiple assignments).  I've appended a patch.

Thanks for that patch. Actually it fixes a bug in an old patch from Sven to
fix some fignore bug. It was sometime in march or april, and for some reason
it did not get into the baseline (there were a lot of patches for fignore in
that time, and somehow that was forgotten).

Zoltan

Completion quirks

[Wayne Davison]

My normal completion options have been to have "auto_list" set and nothing
else.  With this setup there has been a long-standing quirk that if you
hit the completion key with a string that exactly matches a possible
completion, zsh would choose that match even if other (longer) matches
exist.  Just today I installed hzoli10.1+ (including patch2) and its
behavior is different but also wrong -- it chooses one of longer matches.

For example, in one directory of mine I have some picture processing
binaries:

ppmquant	pp	ppr	pp.sh	ppmmerge	ppmhist

If I type "ls pp" and hit tab using zsh 2.6 beta8, it generates a space.
Hitting tab again would start a new completion.

If I use zsh 2.6 beta10hzoli10.1+, it generates "ls ppmhist" -- the last
item in the (unsorted) directory (I don't know if that's significant).
If I hit tab a second it seems to try to treat it as a menu complete (even
though it's not turned on), but fails to update correctly -- I get this:
"ls ppmhist mhist".

Turning on "menu_complete" in hzoli10.1+ behaves exactly the same way.

Turning on "auto_menu" without menu_complete also fails, but in a
different way:  it displays "ls ppmhist " (no beep).  One more tab beeps
and backs up a space.  Another tab displays "ls ppmhist .sh".  Another
tab displays "ls ppmhist mhist".

Turning on "auto_menu" in combination with menu_complete actually works,
even though the documentation says that auto_menu is overridden by
menu_complete.  The behavior in this case is to beep and list the choices
on the first tab, and then start menu-completion with proper screen
updating on subsequent tabs.  I like this behavior a lot, so I've made
it my new default, so for the moment I'm happy.

I'm running zsh this under SCO 3.2v4.2 using gcc 2.7.0 -- is anyone
else having a problem with this?

..wayne..

Re: Completion quirks

[Zefram]

>My normal completion options have been to have "auto_list" set and nothing
>else.  With this setup there has been a long-standing quirk that if you
>hit the completion key with a string that exactly matches a possible
>completion, zsh would choose that match even if other (longer) matches
>exist.

The REC_EXACT option does this.  It would be helpful, when posting this
kind of query, for you to include a *complete* list of option
settings.  Completion is affected by a great many options.

>        Just today I installed hzoli10.1+ (including patch2) and its
>behavior is different but also wrong -- it chooses one of longer matches.

Curious.  Setting REC_EXACT, I got the same behaviour.  My non-hzoli beta10 plus lots of patches picks the right match, as does plain beta10.

[...]
>If I use zsh 2.6 beta10hzoli10.1+, it generates "ls ppmhist" -- the last
>item in the (unsorted) directory (I don't know if that's significant).
>If I hit tab a second it seems to try to treat it as a menu complete (even
>though it's not turned on), but fails to update correctly -- I get this:
>"ls ppmhist mhist".
>
>Turning on "menu_complete" in hzoli10.1+ behaves exactly the same way.
>
>Turning on "auto_menu" without menu_complete also fails, but in a
>different way:  it displays "ls ppmhist " (no beep).  One more tab beeps
>and backs up a space.  Another tab displays "ls ppmhist .sh".  Another
>tab displays "ls ppmhist mhist".

With hzoli10 I got this behaviour, and also with my own patched beta10
(though starting with the correct match).  This problem is almost
certainly a result of my completion list patches (which I can't test
with every option, though I did give it a bit of a work out).  Plain
beta10 for me misbehaved on the second completion, much in the way you
describe, so I think it is safe to say that REC_EXACT is, for the
moment, broken.  I'll see what I can do...

-zefram

P.S.  Can we expect an beta11-test release any time soon, Richard?