Re: Completion quirks

[Zefram <A.Main@dcs.warwick.ac.uk>]

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