From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19955 invoked from network); 13 Mar 2000 10:01:24 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Mar 2000 10:01:24 -0000 Received: (qmail 22681 invoked by alias); 13 Mar 2000 10:01:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10107 Received: (qmail 22673 invoked from network); 13 Mar 2000 10:01:12 -0000 Date: Mon, 13 Mar 2000 11:01:11 +0100 (MET) Message-Id: <200003131001.LAA18234@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Thu, 9 Mar 2000 16:41:51 +0300 Subject: PATCH: RE: Matching against file suffix Andrej Borsenkow wrote: > > The simple 'r:|.=* r:|=*' works for me, i.e. `foo .../.texi' > > gives me the *.texi files. > > > > Well, I never could completely grok matchers :-) > > Still, it seems, that with above matcher zsh considers only first dot. E.g. > > zstyle ':completion:*:*:files' matcher 'r:|.=* r:|=*' > bor@itsrm2% l > WinNT/ patches/ zsh-3.1.6-dev-15.tar.gz > zsh-3.1.6-dev-16.tar.gz zsh-3.1.6-dev-17.tar.gz zsh-3.1.6-dev-18.tar.gz > zsh-3.1.6-dev-19.tar.gz zsh-3.1.6.tar.gz > bor@itsrm2% l .gz > beeps, but > bor@itsrm2% l .1 > bor@itsrm2% l zsh-3.1.6.tar.gz > Completing file > zsh-3.1.6-dev-15.tar.gz zsh-3.1.6-dev-16.tar.gz zsh-3.1.6-dev-17.tar.gz > zsh-3.1.6-dev-18.tar.gz zsh-3.1.6-dev-19.tar.gz zsh-3.1.6.tar.gz > > I vaguelly remember, that it was once done on purpose. While I agree, that it may be > useful at times - is it possible to have alternate way that matches separators as well? Or > some other way to get the above? > > In the above case I'd like being able to say > > gzcat -19TAB (or even -6-19) > and get it expanded to zsh-3.1.6-dev-19.tar.gz (You may call me spineless, but I had a bit of free time at the weekend, so I had a look...) This add `**' as a variation of `*' in match specs that should allow such patterns to also match the anchor -- see Andrej's description above. I haven't tested that very intensively, so, Andrej (or anybody else who likes this): could you try it some more, please? Bye Sven diff -ru ../z.old/Doc/Zsh/compwid.yo Doc/Zsh/compwid.yo --- ../z.old/Doc/Zsh/compwid.yo Mon Mar 13 10:51:23 2000 +++ Doc/Zsh/compwid.yo Mon Mar 13 10:58:11 2000 @@ -796,12 +796,14 @@ like normal character classes. In anchor patterns correspondence classes also behave like normal character classes. -The pattern var(tpat) may also be a single star, `tt(*)'. This means -that the pattern on the command line can match any number of characters -in the trial completion. In this case the pattern must be anchored (on -either side); the var(anchor) then determines how much of the trial -completion is to be included --- only the characters up to the next -appearance of the anchor will be matched. +The pattern var(tpat) may also be one or two stars, `tt(*)' or +`tt(**)'. This means that the pattern on the command line can match +any number of characters in the trial completion. In this case the +pattern must be anchored (on either side); in the case of a single +star, the var(anchor) then determines how much of the trial completion +is to be included --- only the characters up to the next appearance of +the anchor will be matched. With two stars, substrings matched by the +anchor can be matched, too. Examples: @@ -862,6 +864,14 @@ likewise for the second dot, and replaces the empty strings before the anchors, giving tt(c)[tt(omp)]tt(.s)[tt(ources)]tt(.u)[tt(nix)], where the last part of the completion is just as normal. + +With the pattern shown above, the string `tt(c.u)' could not be +completed to `tt(comp.sources.unix)' because the single star means +that no dot (matched by the anchor) can be skipped. By using two stars +as in `tt(r:|.=**)', however, `tt(c.u)' could be completed to +`tt(comp.sources.unix)'. This also shows that in some cases, +especially if the anchor is a real pattern, like a character class, +the form with two stars may result in more matches than one would like. The second specification is needed to make this work when the cursor is in the middle of the string on the command line and the option diff -ru ../z.old/Src/Zle/complete.c Src/Zle/complete.c --- ../z.old/Src/Zle/complete.c Mon Mar 13 10:51:17 2000 +++ Src/Zle/complete.c Mon Mar 13 10:58:11 2000 @@ -253,8 +253,11 @@ return pcm_err; } word = NULL; - wl = -1; - s++; + if (*++s == '*') { + s++; + wl = -2; + } else + wl = -1; } else { word = parse_pattern(name, &s, &wl, 0, &err); diff -ru ../z.old/Src/Zle/compmatch.c Src/Zle/compmatch.c --- ../z.old/Src/Zle/compmatch.c Mon Mar 13 10:51:17 2000 +++ Src/Zle/compmatch.c Mon Mar 13 10:58:12 2000 @@ -75,7 +75,7 @@ for (; m; m = m->next) { if ((!m->flags && m->wlen > 0 && m->llen > 0) || - (m->flags == CMF_RIGHT && m->wlen == -1 && !m->llen)) { + (m->flags == CMF_RIGHT && m->wlen < 0 && !m->llen)) { *q = n = (Cmlist) zhalloc(sizeof(struct cmlist)); n->matcher = m; q = &(n->next); @@ -546,7 +546,7 @@ } else t = match_str(l + llen + moff, tp + moff, NULL, 0, NULL, 0, 1, part); - if (t || !both) + if (t || (mp->wlen == -1 && !both)) break; } } @@ -1008,7 +1008,7 @@ while (len) { for (t = 0, ms = bmatchers; ms && !t; ms = ms->next) { mp = ms->matcher; - if (mp && mp->flags == CMF_RIGHT && mp->wlen == -1 && + if (mp && mp->flags == CMF_RIGHT && mp->wlen < 0 && !mp->llen && len >= mp->ralen && mp->ralen && pattern_match(mp->right, str, NULL, NULL)) { int olen = str - p, llen; -- Sven Wischnowsky wischnow@informatik.hu-berlin.de