zsh-workers
 help / color / mirror / code / Atom feed
* PATCH: 3.1.5-pws-10 and then some: _match_test is too strict
@ 1999-03-03  8:36 Bart Schaefer
  0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 1999-03-03  8:36 UTC (permalink / raw)
  To: zsh-workers

I just applied all the patches from Sven, Peter, and Matt that have
appeared since pws-10, configured with --disable-dynamic, compiled
without a hitch, ran the new zsh, set up my fpath and sourced the
compinit file.

And no file-related completions worked for me at all.

After staring at the output of repeated completions with `set -vx` in
effect, I finally concluded that the culprit is _match_test.  It seems
that you must have at least one compctl -M spec in effect in order for
_match_test to return true.  Since I don't have any compctl -M at all
and don't particularly want any at the moment, this would appear to be
a minor drawback to the current system.

I realize _match_test is intended to be edited to reflect the user's
personal matcher settings, but it ought to work "out of the box" in a
`zsh -f` situation, oughtn't it?

The following appears to deal with it; does it break something when
there *are* matcher specs?  What's the point of testing for exactly
the first matcher spec, anyway?

Index: Completion/Base/_match_test
===================================================================
diff -u -r1.2 _match_test
--- _match_test	1999/03/03 07:31:03	1.2
+++ _match_test	1999/03/03 08:28:46
@@ -12,4 +12,4 @@
 # match specifications and modify the function `_match_pattern' to build the
 # pattern to use in the calling function.
 
-(( compstate[matcher] == 1 ))
+(( compstate[matcher] <= 1 ))


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: PATCH: 3.1.5-pws-10 and then some: _match_test is too strict
@ 1999-03-03  8:58 Sven Wischnowsky
  0 siblings, 0 replies; 2+ messages in thread
From: Sven Wischnowsky @ 1999-03-03  8:58 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> The following appears to deal with it; does it break something when
> there *are* matcher specs?  What's the point of testing for exactly
> the first matcher spec, anyway?

Sorrysorrysorry. My fault (of course). In the last big patch I made
`compstate[matcher]' be zero when there are no match specs at all
(previously it was `one' in this case, which looked wrong). And then I 
forgot to change the test.

Bart's patch is the correct solution.

Thanks.

Sorry.

Bye
 Sven


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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1999-03-03  8:59 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-03  8:36 PATCH: 3.1.5-pws-10 and then some: _match_test is too strict Bart Schaefer
1999-03-03  8:58 Sven Wischnowsky

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).