PATCH: Re: ignored-patterns giving correction a go

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> On Mar 17, 10:05am, Sven Wischnowsky wrote:
> } Subject: Re: ignored-patterns giving correction a go
> }
> } I use something like:
> } 
> }   zstyle :completion::::: completer _next_tags _expand _complete \
> }                                     _complete _match _correct \
> }                                     _approximate _prefix
> 
> BTW, there's no doc for _next_tags

Huh? 10108 contains a hunk for it.

> ... what happens if you invoke it as
> a widget but it's NOT in your completer list?

The end of civilisation as we know it...

It will continue to exclude the tags that were excluded the last time
one called _next_tags (the bindable command).

> }   zstyle ':completion:*:complete-2:*' prefer-ignored yes
> }   zstyle ':completion:*:(correct|approximate|prefix)-1:*' prefer-ignored yes
> 
> Obviously the documentation for using a completer twice doesn't belong
> just under the matcher-list spec any more.

No, it's only used for matcher-list and prefer-ignored, as documented.
Just so that I don't forget it, the patch below takes back a part of
your doc change. *But*: should we change it so that your documentation 
becomes true? I played with this idea, too... One problem: approximate 
(and correct) use the same syntax already to include the number of
errors currently accepted. So we would have `complete-1',
`correct-1-2' and so on (if we want to make to use it for all
completers which I think we should if we do it for one).

> } All this alternate-set stuff looks like a hack. [...] The problem is
> } that if we remove the alternate set stuff for new completion, we'll
> } have trouble re-implementing the behaviour of $fignore, at least when
> } we want it to have the exact same effect.
> 
> The tricky bit is really the fail-over behavior, isn't it?  That is,
> the way the alternate set is automatically used if the "real" set is
> empty?

Right. More precisely: with the style-control we have now (or will
soon have) we can easily get the behaviour that the excluded matches
are used later, but only while the calling function is still running,
unless we want to let users call _complete again at the very end to
generate the matches excluded before (and in that case we would need a 
way to say that for that call to _complete the ignored-patterns style
is not to be used, which brings us back to the `complete-<n>' naming
in the completer field above).

> So what if we just made the alternate set a group of its own, on the
> same level as the -default- group, e.g. -alternate-.  Change the -a
> option of compadd to require an argument, `-a alternate-group-name',
> that, when used with `-[JV] group-name' and `-F array' names the group
> into which the completions matching the -F patterns are placed; the
> sorting of that group is the same as for the -[JV], -[12] apply, etc.
> When no -a is given the -alternate- group is used by -F, and when -a
> is given with no -[JV], the completions that don't match the -F pattern
> go into -default-.

Yes, I once thought about using a different group, too. Hadn't thought 
about allowing users to give it a name, though... Hm. What makes me
uneasy about it is that this would make it even more complicated.

> (I'd almost rather pick a different option that -a and eliminate -a
> entirely, to break noisily any completion functions that now use -a
> without an argument; but -A is already taken, as are most of the other
> sensible letters.)
> 
> Then make the default completion behavior be as if the tag-order were
> the array (-default- -alternate-).  If in any context the tag-order
> style is overridden, the user must explicitly name -alternate- (or any
> group passed with -a by other completion functions) to have it used.
> Document this, of course.

We are then back at the problem that the -alternate- group would be
used too early. In comparison to the alternate set behaviour we have
now, I mean. One question I constantly find me asking myself is if we
really want it the way we have it now. And the two styles working
around/with the current behaviour make me think that it would be
better to completely remove it...

> ...
> 
> One problem is that I don't see how you can eliminate the current
> alternate-set support from the C code and still have fignore work for
> old compctl, but maybe you have an idea for going about that.  Or
> maybe that code would just go unused in the new system.

...exactly in this. That's what I was thinking about. Let ignored
matches be really ignored. Let users say explicitly if they want to
see them. And probably: when they want to see them.

We would need a convenient way to configure this, then.

> (What happens right now if you call
> 	compadd -V group ...
> and later
> 	compadd -J group ...
> that is, specify some sorted and some unsorted matches for the same
> group?)

Different name spaces. The patch to the doc below makes this clearer.

> (What's the point of setting groups[2] inside the _tags loop in _files?
> it doesn't appear to get used anywhere after line 19 where it's copied
> into the opts array.)

Ugh. I shouldn't have stuffed that into $opts. No patch for this,
because I'm fiddling with the completion code at home and _files is
the next on my list anyway...

> } Some more about 10134: after having thought about it some more, I
> } begin to like the suggestion with `tag-order tag=method ...' with the
> } shortcut `tag-order foo'.
> 
> The only issue I have with this is that it increases the number of
> similar zstyle commands one must give to configure a behavior.

Yes, that's the part I didn't like about it.

>  Here's
> your example from 10134:
> 
> }   zstyle ... tag-order foo=files bar=files
> }   zstyle '...:foo' file-patterns '*.ps'
> 
> Presumably the '...' part in both of those lines is, in many cases,
> going to be the same.  And then you need to repeat it _again_ to give
> the patterns for `bar'.  I find myself wishing for some way to merge
> them, maybe something like
> 
>     zstyle ... tag-order foo=files bar=files \
> 	    + foo file-patterns '*.ps' \
> 	    + bar file-patterns '*.pdf'
> 
> That specific example would make the word `+' magic, which might not be
> a good idea ... but we're running out of metacharacters that don't need
> to be annoyingly quoted.

Hm, yes, hadn't thought about that. Looks like somethink I could start 
to like...

> I was going to try to reply in some detail to 10134, but I'm out of time
> and (other than preferring the tag=method form to having yet _another_
> set of styles to name method-tags) it's probably better if Sven just
> tries things out and reports how well he thinks they work.

As I said, I have implemented most of it (not yet finished, no docs
and no time today or this evening, so you'll have to wait a bit more).

Currently I don't even plan to use the term `method' any more. I'm
thinking about something like `tag aliases'. User-defined names for
offered tags which are then used for the lookup instead of the
original tag. It works quite nicely, but we'll really have to look
closely at ways to make configuration easier.

Bye
 Sven

diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Mon Mar 20 10:04:15 2000
+++ Doc/Zsh/compsys.yo	Mon Mar 20 10:33:12 2000
@@ -292,16 +292,11 @@
 )
 item()(
 The var(completer) currently active, i.e. the name of the completer
-function without the leading underscore, followed by a minus sign and a
-number.  The number is 1 on the first call to a completer, 2 on the second
-call to the em(same) completer, etc.; this is used to provide fine control
-of when a completion style is used (see `Standard Styles' in
-ifzman(the section `Completion System Configuration' below)\
-ifnzman(noderef(Completion System Configuration)) 
-for examples).  Such a completer is in overall control of how completion
-is to be performed; `tt(complete)' is the basic one for ordinary
-completion, but completers may perform various related tasks such as
-correction, or modify the behaviour of a later completer (see
+function without the leading underscore. Such a completer is in
+overall control of how completion is to be performed; `tt(complete)'
+is the basic one for ordinary completion, but completers may perform
+various related tasks such as correction, or modify the behaviour of a
+later completer (see
 ifzman(the section `Control Functions' below)\
 ifnzman(noderef(Control Functions)) 
 for more information).  
diff -ru ../z.old/Doc/Zsh/compwid.yo Doc/Zsh/compwid.yo
--- ../z.old/Doc/Zsh/compwid.yo	Mon Mar 20 10:04:15 2000
+++ Doc/Zsh/compwid.yo	Mon Mar 20 10:49:47 2000
@@ -450,7 +450,8 @@
 Gives the name of the group of matches the words should be stored in.
 )
 item(tt(-V) var(name))(
-Like tt(-J) but naming a unsorted group.
+Like tt(-J) but naming a unsorted group. These are in a different name 
+space than groups created with the tt(-J) flag.
 )
 item(tt(-1))(
 If given together with the tt(-V) option, makes

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx