From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-12057-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 19216 invoked from network); 24 Jun 2000 19:55:25 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 24 Jun 2000 19:55:25 -0000
Received: (qmail 8460 invoked by alias); 24 Jun 2000 19:55:18 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 12057
Received: (qmail 8449 invoked from network); 24 Jun 2000 19:55:17 -0000
Date: Sat, 24 Jun 2000 12:54:49 -0700 (PDT)
From: Wayne Davison <wayned@users.sourceforge.net>
X-Sender: wayne@phong.blorf.net
To: Zsh Workers <zsh-workers@sunsite.auc.dk>
Subject: A couple completion glitches
Message-ID: <Pine.LNX.4.21.0006241215430.3626-100000@phong.blorf.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I've noticed that the new completion system won't ever complete a name
that matches the $fignore list, even if it is the only completion
possible.  The old completion system would go ahead and complete such
names if it was the only thing to do.  For example, if I have ".old"
in $fignore and the files "foo" and "foo.old" exist, both systems
handle "f<tab>" the same -- it expands to "foo ".  I used to be able
to append a '.', press <tab>, and get "foo.old", now I can't.  Is
this intentional?

Secondly, there seems to be an inconsistency in the handling of glob
characters.  For instance:

    % autoload -U compinit
    % compinit -D
    % zstyle ':completion:*' completer _expand _complete
    % bindkey '^i' complete-word
    % cd ~
    % touch foo{1..3}
    % ls ~/foo*<tab>

...and nothing happens!  Removing the "~/" works around the problem:

    % ls foo*<tab>

This results in the following menu expansion:

    % ls foo*
    foo*             foo1 foo2 foo3
    foo1       foo2       foo3

Strangely, setting "zstyle ':completion:*' original false" doesn't
remove the "foo*" from the list -- should it?

One more inconsistency results from the same setup, and this expansion:

    % ls foo?<tab>

This results in a slightly differ ordering (due to ASCII sorting):

    % ls foo1 foo2 foo3
    foo1 foo2 foo3   foo?
    foo1       foo2       foo3

In my mind, I would like it to always order the full expansion and the
original string into the same places, regardless of ASCII order (to
make it more consistent).  Perhaps always put the multi-item expansion
first and the original string last?

..wayne..