PATCH: Re: ignored-patterns giving correction a go

PATCH: Re: ignored-patterns giving correction a go

[Sven Wischnowsky]

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@informatik.hu-berlin.de

Re: PATCH: Re: ignored-patterns giving correction a go

[Bart Schaefer]

On Mar 20, 10:56am, Sven Wischnowsky wrote:
} Subject: PATCH: Re: ignored-patterns giving correction a go
}
} Bart Schaefer wrote:
} > BTW, there's no doc for _next_tags
} 
} Huh? 10108 contains a hunk for it.

Hrm; I must have been looking at an un-rebuilt zsh.info ... it is indeed
there.  Sorry.

} > ... 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...

The point being that perhaps it should not be bound to a key by compinit
if it's not in the completer list by default ...

[Trailing -number on completer context]
} 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?

It's too bad those things have to be wedged into the context string.
It feels as though they should be somewhere else.

} 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

I don't think I like having two such suffixes on the same completer.

} > 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'
} 
} 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'm not especially worried about it being complicated for people who are
deep enough into it to be writing functions that use alternate sets.  The
people who have to configure it are the ones who should get off easy.

(Back when we first started discussing the new completion system, my idea
was that lots of people would need to write their own completers, and I
was worried about making the functions easy to understand.  Now we have a 
huge library of highly configurable functions, so hardly anyone is going
to need to write one ... it _should_ be easier to configure the ones we
have than it is to write new ones ...)

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

RE: PATCH: Re: ignored-patterns giving correction a go

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > > The point being that perhaps it should not be bound to a key by compinit
> > > if it's not in the completer list by default ...
> > 
> > Ah, right. The patch does that (I think this is saver than changing
> > the default completer value).
> > 
> 
> Looks like you forgot to include it ...

Ahem.

Bye
 Sven

diff -ru ../z.old/Completion/Commands/_next_tags Completion/Commands/_next_tags
--- ../z.old/Completion/Commands/_next_tags	Mon Mar 20 11:07:24 2000
+++ Completion/Commands/_next_tags	Mon Mar 20 11:32:04 2000
@@ -1,4 +1,13 @@
-#compdef -k complete-word \C-xn
+#autoload
+
+# To use this, put _next_tags at the beginning of the completer style,
+# define it as a completion widget and bind it to a key, e.g.:
+#
+#  zle -C _next_tags complete-word _next_tags
+#  bindkey '^Xn' _next_tags
+#
+# Makes it be bound to ^Xn.
+
 
 # Main widget/completer.
 
diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Mon Mar 20 11:07:07 2000
+++ Doc/Zsh/compsys.yo	Mon Mar 20 11:34:00 2000
@@ -1867,8 +1867,8 @@
 var(N), complete the var(N)th most recently modified file.  Note the
 completion, if any, is always unique.
 )
-findex(_next_tags (^Xn))
-item(tt(_next_tags (^Xn)))(
+findex(_next_tags)
+item(tt(_next_tags))(
 This allows to complete types of matches that are not immediately
 offered because of the setting of the tt(tag-order) style. After a
 normal completion was tried, invoking this command makes the matches
@@ -1878,6 +1878,12 @@
 contain tt(_next_tags) as its first string. With that, the normal key
 binding (normally tt(TAB)) can be used to complete the matches shown
 after the call to tt(_next_tags).
+
+Normally, this command is not bound to a key. To invoke it with, say
+`tt(^Xn)', one would use:
+
+example(zle -C _next_tags complete-word _next_tags
+bindkey '^Xn' _next_tags)
 )
 findex(_read_comp (^X^R))
 item(tt(_read_comp (^X^R)))(

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

Re: PATCH: Re: ignored-patterns giving correction a go

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> [_next_tags]
> } > ... 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...
> 
> The point being that perhaps it should not be bound to a key by compinit
> if it's not in the completer list by default ...

Ah, right. The patch does that (I think this is saver than changing
the default completer value).

> [Trailing -number on completer context]
> } 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?
> 
> It's too bad those things have to be wedged into the context string.
> It feels as though they should be somewhere else.
> 
> } 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
> 
> I don't think I like having two such suffixes on the same completer.

Yep, that's why I didn't do it.

> } > 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'
> } 
> } 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'm not especially worried about it being complicated for people who are
> deep enough into it to be writing functions that use alternate sets.  The
> people who have to configure it are the ones who should get off easy.

It's also that the alternate set stuff as it is now only gives you all 
or nothing. One can't say that one *never* wants to see some
matches. As soon as there are no other matches, the alternate set code 
will give you the excluded ones. If we implement ways to completely
handle such exclusions-or-not in shell code, users would be able to
say which matches they never want and which matches they may want --
and when.

> (Back when we first started discussing the new completion system, my idea
> was that lots of people would need to write their own completers, and I
> was worried about making the functions easy to understand.  Now we have a 
> huge library of highly configurable functions, so hardly anyone is going
> to need to write one ... it _should_ be easier to configure the ones we
> have than it is to write new ones ...)

Yes.

Bye
 Sven


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