Completion quirks

[Wayne Davison <wayne@xxxxxxxxxxxxxxxxxx>]

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