PATCH: Re: _match still does not work in _path_files

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx