From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7625 invoked from network); 10 Oct 2001 13:16:27 -0000 Received: from unknown (HELO sunsite.dk) (130.225.247.90) by ns1.primenet.com.au with SMTP; 10 Oct 2001 13:16:27 -0000 Received: (qmail 22572 invoked by alias); 10 Oct 2001 13:16:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16002 Received: (qmail 22560 invoked from network); 10 Oct 2001 13:16:21 -0000 From: Sven Wischnowsky MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15300.14000.293820.150108@gargle.gargle.HOWL> Date: Wed, 10 Oct 2001 13:53:20 +0200 To: zsh-workers@sunsite.dk Subject: Re: `expand' style with prefix and matchers In-Reply-To: <11493.1002634622@csr.com> References: <11493.1002634622@csr.com> X-Mailer: VM 6.92 under 21.1 (patch 3) "Acadia" XEmacs Lucid Peter Stephenson wrote: > ... > > If I have > zstyle ':completion:*' expand prefix suffix > however, I get the list > Completing file > bc01/test/h-b-12-p bc01/testsclk/h-b-12-p bc01/traces/h-b-12-p > Neither of the other two directories contain a match for h-b-12-p. > > It looks like overeagerness to apply the `prefix' style even if there is > actually only one possible match --- I would guess it's applying it before > it's done the stuff with matchers. > > Probably the worst aspect is that the same problem shows up with > ~/bc01/test/h-b-12-p, because the first part matches testsclk, which is a > bit obscure since it doesn't obviously have anything to do with multiple > paths. In this version, I can tickle the bug without the `suffix' part of > the expand style. I was slightly irritated at first, too. But then... the match spec that makes h-b-12-p match isn't the first on in your matcher-list style, right? What happens is that _path_files collects the matching prefixes for the non-matching suffixes every time, in this case for the first match spec where h-b-12-p doesn't match. And then the expand style says to accept them. So we should only accept them when we are trying the last spec from the matcher-list style. At least that sounds sensible, doesn't it? Bye Sven Index: Completion/Unix/Type/_path_files =================================================================== RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v retrieving revision 1.12 diff -u -r1.12 _path_files --- Completion/Unix/Type/_path_files 2001/10/05 11:18:37 1.12 +++ Completion/Unix/Type/_path_files 2001/10/10 11:50:22 @@ -656,9 +656,13 @@ # If we are configured to expand paths as far as possible and we collected # expanded paths that are different from the string on the line, we add -# them as possible matches. +# them as possible matches. Do that only if we are currently trying the +# last entry in the matcher-list style, otherwise other match specs might +# make the suffix that didn't match this time match in one of the following +# attempts. -if zstyle -t ":completion:${curcontext}:paths" expand prefix && +if [[ _matcher_num -eq ${#_matchers} ]] && + zstyle -t ":completion:${curcontext}:paths" expand prefix && [[ nm -eq compstate[nmatches] && $#exppaths -ne 0 && "$linepath$exppaths" != "$eorig" ]]; then PREFIX="${opre}" -- Sven Wischnowsky wischnow@informatik.hu-berlin.de