RE: PATCH: Re: _match still does not work in _path_files

RE: PATCH: Re: _match still does not work in _path_files

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > Believe it or not, it works correctly. I always said, that with
> > matching (a.k.a. GLOB_COMPLETE), the match specs are not used, and
> > functions like `_path_files' rely on them.
> 
> I do not believe it :-) It did work for me in all 3.1.5* and in 3.1.6-pws-XX
> (well, at least in pws-1 and pws-2). It stopped to work now. Unless there was a
> good reason to break it ... may I have it back?

The reason was the request to have completion inside braces work if
the brace is in the path prefix. That required to use a `compadd' with 
matching when we finally add the matches and since the match specs
aren't used when glob-completion is done, the prefix line-pattern
doesn't match the prefix added with the matches.

The patch below implements some kind of mixed-matching style. Even
with glob-complete behaviour it will try to match the prefix using the 
match specs currently in effect. This is as far as we can get. Is it
enough?

The patch also makes the path-expand behaviour a bit more powerful.
I.e. it changes the way the `path_expand' key is used (NOTE
incompatible change): if the value contains the substring `prefix',
the prefix is expanded as far as possible (this is what was previously 
achieved by setting it to any non-empty value). If the value contains
`suffix', it will add possible files in the suffix when not using
menu-completion, i.e. it will try to produce an unambiguous string
which is as long as possible (this was previously the default
behaviour).

People like Andrej might want to leave it unset.

If anyone has an idea how we could make it find out when it would be
interesting to expand the suffix anyway, let me know.


In a different message:

> Ahem ... but why is menu completion started for the last path component in the
> first place? I expect it to be started for {functions,functions.old} - the first
> ambiguous part. And I bet it was - once.
> 
> I tested it in zsh-3.1.6 and there _match works :-) and look what happens:
> 
> itsrm2% l /t/s/z/f*/_<TAB>
> itsrm2% l /tools/share/zsh/functions/_
> functions/      functions.old/
> 
> press TAB once more and selection is started for the first ambiguous component:

This works for me again. If it still doesn't work for you, I need to
know your compconfig.

> I (from a user's point of view) fail to see, how /t/s/z/f/_ differs from
> /t/s/z/f*/_ - it has exactly and precisely the same meaning.

For me, they are completely different. The second one is a pattern
(note: the *whole* string) and even though the patch should make it
work the way you want it, I think there is still a point in saying
that *should* be treated differently. If I ever try completion on a
pattern (which is seldom nowadays, I mostly use spiffy xor'ed global
match specs), I would probably want it to be interpreted as `I know
what I'm doing here, I give you a pattern and you should handle
exactly that and nothing else'. I.e. it shouldn't use match-specs
(which is just a different type of pattern matching for me).

Bye
 Sven

diff -u -r oldsrc/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- oldsrc/Zle/zle_tricky.c	Mon Oct 18 09:50:07 1999
+++ Src/Zle/zle_tricky.c	Mon Oct 18 10:05:37 1999
@@ -4118,23 +4118,6 @@
 		    llpl -= pl;
 		    lpre += pl;
 		}
-		if (comppatmatch && *comppatmatch) {
-		    int is = (*comppatmatch == '*');
-		    char *tmp = (char *) zhalloc(2 + llpl + llsl);
-
-		    strcpy(tmp, lpre);
-		    tmp[llpl] = 'x';
-		    strcpy(tmp + llpl + is, lsuf);
-
-		    tokenize(tmp);
-		    remnulargs(tmp);
-		    if (haswilds(tmp)) {
-			if (is)
-			    tmp[llpl] = Star;
-			if ((cp = patcompile(tmp, 0, NULL)))
-			    haspattern = 1;
-		    }
-		}
 	    }
 	    /* Now duplicate the strings we have from the command line. */
 	    if (dat->ipre)
@@ -4195,6 +4178,23 @@
 			lsuf[llsl - lsl] = '\0';
 		    else
 			*argv = NULL;
+		}
+		if (comppatmatch && *comppatmatch) {
+		    int is = (*comppatmatch == '*');
+		    char *tmp = (char *) zhalloc(2 + llpl + llsl);
+
+		    strcpy(tmp, lpre);
+		    tmp[llpl] = 'x';
+		    strcpy(tmp + llpl + is, lsuf);
+
+		    tokenize(tmp);
+		    remnulargs(tmp);
+		    if (haswilds(tmp)) {
+			if (is)
+			    tmp[llpl] = Star;
+			if ((cp = patcompile(tmp, 0, NULL)))
+			    haspattern = 1;
+		    }
 		}
 	    }
 	    if (*argv) {
diff -u -r oldcompletion/Core/_main_complete Completion/Core/_main_complete
--- oldcompletion/Core/_main_complete	Mon Oct 18 09:48:51 1999
+++ Completion/Core/_main_complete	Mon Oct 18 10:12:31 1999
@@ -60,6 +60,7 @@
 
 _lastdescr=( "\`${(@)^_lastdescr:#}'" )
 if [[ compstate[nmatches] -eq 0 &&
+      compstate[matcher] -eq compstate[total_matchers] &&
       -n "$compconfig[warning_format]" && $#_lastdescr -ne 0 ]]; then
   local str
 
diff -u -r oldcompletion/Core/_path_files Completion/Core/_path_files
--- oldcompletion/Core/_path_files	Mon Oct 18 09:48:51 1999
+++ Completion/Core/_path_files	Mon Oct 18 10:05:37 1999
@@ -347,7 +347,7 @@
 	SUFFIX=""
       fi
 
-      if [[ -n $menu ]]; then
+      if [[ -n $menu || "$compconfig[path_expand]" != *suffix* ]]; then
         [[ -n "$compconfig[path_cursor]" ]] && compstate[to_end]=''
         if [[ "$tmp3" = */* ]]; then
 	  compadd -Qf -p "$linepath${testpath:q}" -s "/${tmp3#*/}" \
@@ -418,7 +418,7 @@
 
 exppaths=( "${(@)exppaths:#$orig}" )
 
-if [[ -n "$compconfig[path_expand]" &&
+if [[ "$compconfig[path_expand]" = *prefix* &&
       $#exppaths -gt 0 && nm -eq compstate[nmatches] ]]; then
   PREFIX="${opre}${osuf}"
   SUFFIX=""
diff -u -r oldcompletion/Core/compinit Completion/Core/compinit
--- oldcompletion/Core/compinit	Mon Oct 18 09:48:52 1999
+++ Completion/Core/compinit	Mon Oct 18 10:05:37 1999
@@ -368,7 +368,7 @@
 
 # Utility function to call a function if it exists.
 #
-# Usage: call <return> <name> [ <args> ... ]
+# Usage: funcall <return> <name> [ <args> ... ]
 #
 # If a function named <name> is defined (or defined to be autoloaded),
 # it is called. If <return> is given not the string `-' or empty, it is
@@ -385,10 +385,11 @@
 
   shift
 
-  if builtin functions "$1"; then
+  if builtin functions "$1" >& /dev/null; then
     "$@"
     _ret="$?"
     [[ -n "$_name" ]] && eval "${_name}=${_ret}"
+    compstate[restore]=''
     return 0
   fi
   return 1
diff -u olddoc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- olddoc/Zsh/compsys.yo	Mon Oct 18 09:50:35 1999
+++ Doc/Zsh/compsys.yo	Mon Oct 18 10:37:32 1999
@@ -720,9 +720,16 @@
 Finally, the tt(_path_files) function supports two configuration keys.
 startitem()
 item(tt(path_expand))(
-If this is set to any non-empty string, the partially
+If this is set to a string containing `tt(prefix)', the partially
 typed path from the line will be expanded as far as possible even if
-trailing pathname components can not be completed.
+trailing pathname components can not be completed. If it contains the
+substring `tt(suffix)' and normal (non-menu-) completion is used,
+matching names for components after the first ambiguous one will be
+added, too. This means that the resulting string is the longest
+unambiguous string possible, but if menu-completion is started on the
+list of matches generated this way (e.g. due to the option
+tt(AUTO_MENU) being set), this will also cycle through the names
+of the files in pathname components after the first ambiguous one.
 )
 item(tt(path_cursor))(
 If this is set to a non-empty string, the cursor will be left

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Re: _match still does not work in _path_files

[Bart Schaefer]

On Oct 18, 10:38am, Sven Wischnowsky wrote:
} Subject: RE: PATCH: Re: _match still does not work in _path_files
}
} The patch below implements some kind of mixed-matching style. Even
} with glob-complete behaviour it will try to match the prefix using the 
} match specs currently in effect. This is as far as we can get. Is it
} enough?

There's still one thing that bothers me; it's probably not related.  With
the default compconfig:

zagzig% cd /u/l/s/z/f/

Fails to complete to /usr/local/share/zsh/functions/.  The problem is
that _path_files wants there to be something after the final slash that
is a fragment of a directory name.  I vaguely recall some discussion of
a compconfig for something like this, but if there is one I can't find
it -- and given that "cd" doesn't care if the trailing slash is there,
shouldn't this work by default anyway?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

RE: PATCH: Re: _match still does not work in _path_files

[Andrej Borsenkow]

> In a different message:
>
> > Ahem ... but why is menu completion started for the last path
> component in the
> > first place? I expect it to be started for
> {functions,functions.old} - the first
> > ambiguous part. And I bet it was - once.
> >
> > I tested it in zsh-3.1.6 and there _match works :-) and look what happens:
> >
> > itsrm2% l /t/s/z/f*/_<TAB>
> > itsrm2% l /tools/share/zsh/functions/_
> > functions/      functions.old/
> >
> > press TAB once more and selection is started for the first
> ambiguous component:
>
> This works for me again. If it still doesn't work for you, I need to
> know your compconfig.
>

Nope, it still does not work here. This is the ZSH from CVS of Tanaka Akira ...
quite recent, couple of hours (anybody know, how to find exact time when files
have been updated?)

Compare:

bor@itsrm2:/tools/src/zsh-cvs/zsh%> zsh -f
itsrm2% compinit -D
zsh: command not found: compinit
itsrm2% autoload -U compinit; compinit -D
itsrm2% bindkey -e
itsrm2% setopt nolistambiguous
itsrm2% {
cursh> compconf completer='_oldlist:_complete:_match'
cursh> compconf correct_accept='2n'
cursh> compconf correct_prompt='correct to:'
cursh> compconf dumpfile='/home/bor/.zcompdump'
cursh> compconf match_insert='unambig'
cursh> compconf match_original='yes'
cursh> compconf oldlist_list='_match'
cursh> compconf path_cursor='yes'
cursh> }
itsrm2% zmodload complist
itsrm2% SELECTMIN=0
itsrm2% ls /t/s/z/f*/_<TAB>
beeps

but

bor@itsrm2:/tools/src/db-2.7.7/build_unix%> zsh-3.1.6 -f
itsrm2% cd /tools/src/zsh-3.1.6/Completion
itsrm2% fpath=($PWD/*(/))
itsrm2% autoload -U compinit; compinit -D
itsrm2% {
cursh> compconf completer='_oldlist:_complete:_match'
cursh> compconf correct_accept='2n'
cursh> compconf correct_prompt='correct to:'
cursh> compconf dumpfile='/home/bor/.zcompdump'
cursh> compconf match_insert='unambig'
cursh> compconf match_original='yes'
cursh> compconf oldlist_list='_match'
cursh> compconf path_cursor='yes'
cursh> }
itsrm2% SELECTMIN=0
itsrm2% zmodload complist
itsrm2% bindkey -e
itsrm2% setopt nolistambiguous
itsrm2% ls /t/s/z/f*/_<TAB>
itsrm2% ls /tools/share/zsh/functions<CURSOR>/_
functions/      functions.old/

with TAB cycling between functions and functions.old

It is much worse actually; in the above setup as simple as

itsrm2% ls /t/s/z/f/_<TAB>

does not work - it beeps. In 3.1.6 pure I at least get both functions and
functions.old listed (I am still not quite happy with what happens after the
second TAB ...)



/andrej

RE: PATCH: Re: _match still does not work in _path_files

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Compare:
> 
> bor@itsrm2:/tools/src/zsh-cvs/zsh%> zsh -f
> ...
> itsrm2% ls /t/s/z/f*/_<TAB>
> beeps
> 
> but
> 
> bor@itsrm2:/tools/src/db-2.7.7/build_unix%> zsh-3.1.6 -f
> ...
> itsrm2% ls /t/s/z/f*/_<TAB>
> itsrm2% ls /tools/share/zsh/functions<CURSOR>/_
> functions/      functions.old/
> 
> with TAB cycling between functions and functions.old
> 
> It is much worse actually; in the above setup as simple as
> 
> itsrm2% ls /t/s/z/f/_<TAB>
> 
> does not work - it beeps. In 3.1.6 pure I at least get both functions and
> functions.old listed (I am still not quite happy with what happens after the
> second TAB ...)

There was a bug which should be fixed by the patch below. However, the 
rest of what I said the last time when you brought this up is still
valid.

Bye
 Sven

diff -u oldcompletion/Core/_path_files Completion/Core/_path_files
--- oldcompletion/Core/_path_files	Mon Nov  1 09:03:02 1999
+++ Completion/Core/_path_files	Tue Nov  2 15:50:27 1999
@@ -316,7 +316,7 @@
       # collected as the suffixes to make the completion code expand
       # it as far as possible.
 
-      if [[ "$tsuf" = */* ]]; then
+      if [[ "$tpre" = */* ]]; then
         PREFIX="${donepath}${linepath}${cpre}${tpre%%/*}"
 	SUFFIX="/${tsuf#*/}"
       else
@@ -390,8 +390,8 @@
   done
 
   if [[ -z "$tmp4" ]]; then
-    PREFIX="${opre}"
-    SUFFIX="${osuf}"
+    PREFIX="${opre}${osuf}"
+    SUFFIX=""
     compadd -Qf -p "$linepath${testpath:q}" \
 	    -W "$prepath$realpath$testpath" "$ignore[@]" \
 	    "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: Re: _match still does not work in _path_files

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Oct 18, 10:38am, Sven Wischnowsky wrote:
> } Subject: RE: PATCH: Re: _match still does not work in _path_files
> }
> } The patch below implements some kind of mixed-matching style. Even
> } with glob-complete behaviour it will try to match the prefix using the 
> } match specs currently in effect. This is as far as we can get. Is it
> } enough?
> 
> There's still one thing that bothers me; it's probably not related.  With
> the default compconfig:
> 
> zagzig% cd /u/l/s/z/f/
> 
> Fails to complete to /usr/local/share/zsh/functions/.  The problem is
> that _path_files wants there to be something after the final slash that
> is a fragment of a directory name.  I vaguely recall some discussion of
> a compconfig for something like this, but if there is one I can't find
> it -- and given that "cd" doesn't care if the trailing slash is there,
> shouldn't this work by default anyway?

This is one of the cases for `path_expand=prefix', but I agree that it
should be cleverer in doing the right thing automatically.

This makes `_path_files' automatically complete such a path even if
there are no files matching the pattern inside the last directory.
However, it keeps the behaviour of tking the trailing slash as a sign
that one wants to complete inside the directory. I.e. if there *are*
files matching in it, they are added as possible matches immediately.

Ok?

This also made me find some small bugs in the C-code. My last change
to the unambiguous-string insertion heuristic was a bit too eager to
avoid inserting a trailing part. If it was on the line, it should of
course be kept.

And then a rather weird one. Weird in the sense that I wonder why we
haven't noticed it yet. If you add a match as a filename and that's
the name of a directory, do_single() makes the test if it should
append a slash automatically. But if the name added already contains
that trailing slash, it still does the test -- leaving you with two
slashes at the end.

Bye
 Sven

diff -u -r oldsrc/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- oldsrc/Zle/zle_tricky.c	Mon Oct 18 11:54:06 1999
+++ Src/Zle/zle_tricky.c	Mon Oct 18 13:01:58 1999
@@ -7835,7 +7835,7 @@
 	    q = p;
     }
     if (!e && q && !q->orig && !q->olen && (q->flags & CLF_MISS) &&
-	(q->word ? q->wlen : q->llen) < 3) {
+	!(q->flags & CLF_MATCHED) && (q->word ? q->wlen : q->llen) < 3) {
 	q->word = q->line = NULL;
 	q->wlen = q->llen = 0;
     }
@@ -8452,7 +8452,8 @@
 	    if (m->flags & CMF_PARNEST)
 		havesuff = 1;
 	}
-	if ((m->flags & CMF_FILE) || (partest && isset(AUTOPARAMSLASH))) {
+	if (((m->flags & CMF_FILE) || (partest && isset(AUTOPARAMSLASH))) &&
+	    cs > 0 && line[cs - 1] != '/') {
 	    /* If we have a filename or we completed a parameter name      *
 	     * and AUTO_PARAM_SLASH is set, lets see if it is a directory. *
 	     * If it is, we append a slash.                                */
diff -u -r oldcompletion/Core/_path_files Completion/Core/_path_files
--- oldcompletion/Core/_path_files	Mon Oct 18 11:17:49 1999
+++ Completion/Core/_path_files	Mon Oct 18 13:10:14 1999
@@ -277,7 +277,12 @@
       # otherwise this would keep `_files' from completing all filenames
       # if none of the patterns match.
 
-      if [[ "$haspats" = no && -z "$tpre$tsuf" &&
+      if [[ -z "$tpre$tsuf" ]]; then
+        tmp1=( "$tmp2[@]" )
+	addsfx=(-S '')
+	remsfx=()
+	break;
+      elif [[ "$haspats" = no && -z "$tpre$tsuf" &&
 	"$pre" = */ && -z "$suf" ]]; then
 	PREFIX="${opre}${osuf}"
 	SUFFIX=""

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: PATCH: Re: _match still does not work in _path_files

[Sven Wischnowsky]

I wrote:

> diff -u -r oldcompletion/Core/_main_complete Completion/Core/_main_complete
> diff -u -r oldcompletion/Core/compinit Completion/Core/compinit

Oops. I meant to send these separately, but they slipped in, sorry.

These are: a fix for `_main_complete' (the warning message should be
printed only when the last global match spec was tried) and `funcall'.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: PATCH: Re: _match still does not work in _path_files

[Andrej Borsenkow]

>
> ... of the code that makes this happen. `_path_files' adds the
> matching together with possible suffixes to be able to show the
> longest possible unambiguous string to the user. This means that there
> are different matches that would show the same string in the line. To
> avoid showing the same string more than once in a list, the completion
> code hides duplicates. And lists with hidden matches can not be
> completed with menu-selection.
>

Ahem ... but why is menu completion started for the last path component in the
first place? I expect it to be started for {functions,functions.old} - the first
ambiguous part. And I bet it was - once.

I tested it in zsh-3.1.6 and there _match works :-) and look what happens:

itsrm2% l /t/s/z/f*/_<TAB>
itsrm2% l /tools/share/zsh/functions/_
functions/      functions.old/

press TAB once more and selection is started for the first ambiguous component:

itsrm2% l /tools/share/zsh/functions/_
functions/      functions.old/
(after TAB)
itsrm2% l /tools/share/zsh/functions.old/_
functions/      functions.old/

etc.

I (from a user's point of view) fail to see, how /t/s/z/f/_ differs from
/t/s/z/f*/_ - it has exactly and precisely the same meaning.

/andrej

RE: PATCH: Re: _match still does not work in _path_files

[Andrej Borsenkow]

>
> Believe it or not, it works correctly. I always said, that with
> matching (a.k.a. GLOB_COMPLETE), the match specs are not used, and
> functions like `_path_files' rely on them.
>

I do not believe it :-) It did work for me in all 3.1.5* and in 3.1.6-pws-XX
(well, at least in pws-1 and pws-2). It stopped to work now. Unless there was a
good reason to break it ... may I have it back?

/andrej

PATCH: Re: _match still does not work in _path_files

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> With all recent patches to 3.1.6-pws-6 _match still does not work:
> 
> ...
> 
> bor@itsrm2:~%> l /tools/share/zsh
> functions/      functions.old/
> bor@itsrm2:~%> l /t/s/z/f*s<TAB>
> 	beep

Believe it or not, it works correctly. I always said, that with
matching (a.k.a. GLOB_COMPLETE), the match specs are not used, and
functions like `_path_files' rely on them.

With the `path_expand' key set you would at least get what you want
with two TABs.


In a different message:

> 1. Is it possible to force menuselect (special key binding?) in case one match
> is exact? I mean, currently if I have "foo" and "foobar" I get first a list of
> both. Unfortunately, the next TAB starts from the scratch ... thus matching
> "foo" and skipping any menu completion alltogether. (BTW I really think that it
> were better to reuse old matches ... is it still not possible?)

You can always use `oldlist_list='_match:_complete'.

Although you won't like the result I think, because...

> 2. Something strange still happens (with all current patches):
> 
> bor@itsrm2:~%> l /t/s/z/f/_<TAB>
> bor@itsrm2:~%> l /tools/share/zsh/functions/_
> functions/      functions.old/
> 
> (here we have exactly the case of the first question :-) press TAB once more:
> 
> bor@itsrm2:~%> l /tools/share/zsh/functions/_a2ps
> functions/      functions.old/
> 
> Ooops. It starts menu completion - but I have SELECTMIN=0 and expect
> menuselection to be started.

... of the code that makes this happen. `_path_files' adds the
matching together with possible suffixes to be able to show the
longest possible unambiguous string to the user. This means that there 
are different matches that would show the same string in the line. To
avoid showing the same string more than once in a list, the completion 
code hides duplicates. And lists with hidden matches can not be
completed with menu-selection.

The solution would be to add a configuration key to say if
`_path_files' should add different suffixes or just take the original
string from the line even in non-menu-completion.

Maybe we could even try to make it clever by trying to find out if
after the ambiguous path component there is something interesting
enough to insert. But then again, that would probably be worse than
the simple config key solution.

This is left as an exercise for the reader for now. The patch just
fixes a bug I found when trying your second mail (it destroyed its
information about the number of matches added too early). Otherwise
there are just patches for the docs about the match-spec stuff.

Bye
 Sven

diff -u oldsrc/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- oldsrc/Zle/zle_tricky.c	Fri Oct 15 11:45:53 1999
+++ Src/Zle/zle_tricky.c	Fri Oct 15 15:50:36 1999
@@ -157,7 +157,7 @@
 
 /* Number of permanently allocated matches and groups. */
 
-static int permmnum, permgnum;
+static int permmnum, permgnum, lastpermmnum, lastpermgnum;
 
 /* The total number of matches and the number of matches to be listed. */
 
@@ -5123,7 +5123,7 @@
 	    comptoend = ztrdup("match");
 	zsfree(compoldlist);
 	zsfree(compoldins);
-	if (hasoldlist && permmnum) {
+	if (hasoldlist && lastpermmnum) {
 	    if (listshown)
 		compoldlist = "shown";
 	    else
@@ -5359,6 +5359,8 @@
 	    }
 	    permmatches(1);
 	    amatches = pmatches;
+	    lastpermmnum = permmnum;
+	    lastpermgnum = permgnum;
 	} LASTALLOC;
 
 	lastmatches = pmatches;
@@ -8592,7 +8594,7 @@
 	    minfo.cur = NULL;
     }
     if (insgroup) {
-	insgnum = comp_mod(insgnum, permgnum);
+	insgnum = comp_mod(insgnum, lastpermgnum);
 	for (minfo.group = amatches;
 	     minfo.group && (minfo.group)->num != insgnum + 1;
 	     minfo.group = (minfo.group)->next);
@@ -8603,7 +8605,7 @@
 	}
 	insmnum = comp_mod(insmnum, (minfo.group)->mcount);
     } else {
-	insmnum = comp_mod(insmnum, permmnum);
+	insmnum = comp_mod(insmnum, lastpermmnum);
 	for (minfo.group = amatches;
 	     minfo.group && (minfo.group)->mcount <= insmnum;
 	     minfo.group = (minfo.group)->next)
diff -u olddoc/Zsh/compctl.yo Doc/Zsh/compctl.yo
--- olddoc/Zsh/compctl.yo	Fri Oct 15 11:46:05 1999
+++ Doc/Zsh/compctl.yo	Fri Oct 15 15:14:48 1999
@@ -666,7 +666,9 @@
 It is possible by use of the tt(-M) var(spec) flag to specify how the
 characters in the string to be completed (referred to here as the
 command line) map onto the characters in the list of matches produced by
-the completion code (referred to here as the trial completions).
+the completion code (referred to here as the trial completions). Note
+that this is not used if the command line contains a glob pattern and
+the tt(GLOB_COMPLETE) option is set.
 
 The var(spec) consists of one or more matching descriptions separated by
 whitespace. Each description consists of a letter followed by a colon,
diff -u olddoc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- olddoc/Zsh/compsys.yo	Fri Oct 15 11:46:05 1999
+++ Doc/Zsh/compsys.yo	Fri Oct 15 15:19:33 1999
@@ -495,6 +495,9 @@
 `tt(unambig)'. In this case menucompletion will only be started if no
 unambiguous string could be generated that is at least as long as the
 original string.
+
+Note that the matcher specifications defined globally or used by the
+completion functions will not be used.
 )
 item(tt(_expand))(
 This completer function does not really do completion, but instead
diff -u olddoc/Zsh/compwid.yo Doc/Zsh/compwid.yo
--- olddoc/Zsh/compwid.yo	Fri Oct 15 11:46:05 1999
+++ Doc/Zsh/compwid.yo	Fri Oct 15 15:18:12 1999
@@ -329,6 +329,10 @@
 command line will be treated as patterns; if it is `tt(*)', then
 additionally a wildcard `tt(*)' is assumed at the cursor position; if
 it is empty or unset, metacharacters will be treated literally.
+
+Note that the matcher specifications given globally or to one of the
+builtin commands adding matches are not used if this is set to a
+non-empty string.
 )
 item(tt(pattern_insert))(
 Normally this is set to tt(menu), which specifies that menu-completion will

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de