tags and all that...

tags and all that...

[Sven Wischnowsky]

(So, was heisst denn `Grundsatzdiskussion' auf Englisch? ;-)


I've been thinking a lot about this file-patterns stuff we were
discussing. The biggest problem I had with the things suggested was
that there suddenly were two loops or loop-like whatevers: the tags
and the patterns. If we would make _files use only one tag, say
`files' functions like `_next_tags' would be in trouble. So I thought
about several ways how _files could be re-organised. For example we
could make the file-patterns style be inteded to be set globally,
containing tags and patterns for them. _files would then offer all
these tags or, if the style is not set, the tags it uses now with the
meaning they have now. That would use tag-order and friends as usual.

But somehow that didn't feel right. If file-patterns is needed only in 
certain contexts, one would 1) set it for those contexts and 2) set
tag-order for the same contexts, effectively repeating the tag names
and if set for a sufficiently specific context, file-patterns could
already give the ordering, as suggested by Bart. So I was back to the
beginning. Normally I try to generalise the problem in such cases (I
at least I wished I would do that always). Being able to specify ones
own patterns for files is just a special case. Similar things are
already possible with all other types of matches, for example with the 
ignored-patterns style. That made me think about tags some more.

They are kinda schizophrenic currently, aren't they? (And I'm only
talking about tags used when adding matches here...)

I mean, from a completion function's point of view, tags name `ways to
generate matches'. Nothing more. From a user's point of view, they
name a set of matches (trying to avoid the word `group' here, which is 
already used). So, if I may call the `ways to ...' `methods', then we
have the connection that completion functions know about one or
methods to generate matches and, currently, each method can generate
one set of matches. Several styles allow us to say, for example, how
the matches in the sets should be displayed (list-packed, list-colors, 
etc), which matches should not be in them (ignored-patterns) and so
on. Coming back to the _files example, we here have the case that we
have a function knowing about only one method to create matches, but
that can generate different sets of matches. And suddenly the tags
named only the sets, not the method (or the method has multiple names, 
which is equally ugly).

So I would like to first make this cleaner, by really separating
methods from sets of matches. I.e. functions would not call _tags to
say which sets they can generate, they would call, say, _methods to
say *how* they can generate matches. These methods would have
names. Users could say, which sets of matches they want, they would
have names, too. To make things a bit more confusing, let me use `tag' 
for the name of such a set. So users could say something like:

  zstyle ... tag-order foo=files bar=files

Which means that he wants to use the method `files' twice, generating
two sets of matches, named with the tags `foo' and `bar'. Then he can
use all the known styles to say, how the matches in the sets are
generated, how they are listed and so on. E.g.:

  zstyle '...:foo' file-patterns '*.ps'

Of course, we would have to add some default behaviour. And we should
try to make it look like what we have now (that's why I used those
styles in the examples). For tag-order that's relatively simple, I
think: if a value of tag-order does not contain an `=' (or whatever
token we choose):

  zstyle ... tag-order foo

it means, that `foo' is used both to name the method and the set
created. _files is probably the most complicated case: it looks at the 
options it gets (-/, -g, ...) and from that effectively builds a
default `table' mapping tags to methods and patterns (globbed-files to 
whatever was given with -g, directories to `*(-/)', all-files to `*').

But maybe we should make things more method-centered: leave tag-order
unchanged and add a new style looked up for the methods:

  zstyle '...:functions' method-tags non-comp-functions functions
  zstyle '...:non-comp-functions' ignored-patterns '_*'

So, whenever a functions offers to use the method `functions', we try
two generate two sets of matches: `non-comp-functions' and
`functions'. The tag-order style would then say in which order the
tags are tried (and we are back to having to specify tags more than
once).

On the completion function side this would of course mean that we
would have to change all places where _wanted, _tags, etc are used. In 
places where we now don't need a loop we would have to add one,
looping over the tags (sets). Where we now have a loop we would need
two nested loop, the outer one looping over the combinations of tags
and methods and the inner one looping over the methods, calling them
probably more than once, for different tags. Or the outer one looping
over the combinations and multiple inner loops looping over the
tags. That means that we can hide these tag-loops from completion
function writer by putting them into _wanted, _requested and so on
(and giveng them what is now after the `&&' as arguments which will be 
eval'ed).


Maybe I'm completely crazy now, maybe all this isn't that big a
problem to make is attempt something like this separation of methods
and tags. Two things that make me think that it may be worth it are:
Andrej (and my) question if it would be possible to have the matcher
style behave more like matcher-list. With the splitting one could
easily call a method more than once, use different tags and set the
matcher style for these tags. The second thing is my unhappiness with
all this alternate-set business. I haven't though too much about that
yet, but somehow I think there is the potential to get rid of the
alternate set altogether (leaving it only be used by compctl). That
would make me happy.


Actually, the biggest problem I see with all this is to find a good
(convenient) way to configure it. I don't like either of the ways I
showed above very much.


Opinions? Comments?


Bye
 Sven


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

Re: ignored-patterns giving correction a go

[Sven Wischnowsky]

Oliver Kiddle wrote:

> I added the following to by .zshrc after seeing it in Peter's Zsh Guide
> as an example:
> 
> zstyle ':completion:*:functions' ignored-patterns '_*'
> 
> This is often very useful because I don't get functions beginning with
> underscores until I've actually typed the underscore. The trouble is
> that the correction completer gets to have a go before completion is
> tried without the ignored-patterns so for e.g which _co<tab> offers me
> corrections such as co. Is there any way around this?

See 9865.

I use something like:

  zstyle :completion::::: completer _next_tags _expand _complete \
                                    _complete _match _correct \
                                    _approximate _prefix
  zstyle ':completion:*:complete-2:*' prefer-ignored yes
  zstyle ':completion:*:(correct|approximate|prefix)-1:*' prefer-ignored yes

(Simpler setups can obviously be thought of ;-)

All this alternate-set stuff looks like a hack. Initially it was
invented for $fignore with compctl, but I really, really think we
could do it better now with the completion system. And we should do it 
better, I think, it probably the most important part of 10134, for me
at least. 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.

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'. If I'm not completely mistaken, it would
allow us to change the internals, allow much better control and still
don't invalidate anyone's setup. I think I'll play a bit with this at
the weekend.

Bye
 Sven


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

Re: ignored-patterns giving correction a go

[Bart Schaefer]

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 ... what happens if you invoke it as
a widget but it's NOT in your completer list?

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

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

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

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

For the special case of fignore, _files and _path_files can use -a
to name multiple alternate group names, and play with the default
tag-order the way _files already does for globbed-files directories
all-files.  Does that sound like it'll (1) work and (2) be less of a
hack than the present behavior?

An advantage is that you can cause alternates from several groups to
accumulate all in the same place, so for _files you might have the
groups globbed-files directories all-ignored-files all-files, where
all-ignored-files includes both files and paths that matched $fignore.
Not that this is how I'm suggesting it work, I'm just using it by way
of example.

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.

(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?)

(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.)

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

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.

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

PATCH: Documentation for completer field of context

[Bart Schaefer]

On Mar 17,  6:20pm, Bart Schaefer wrote:
} Subject: Re: ignored-patterns giving correction a go
}
} Obviously the documentation for using a completer twice doesn't belong
} just under the matcher-list spec any more.

Patch for that, plus a small fix for the zcompile entry.

Index: Doc/Zsh/builtins.yo
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Doc/Zsh/builtins.yo,v
retrieving revision 1.56
diff -u -r1.56 builtins.yo
--- builtins.yo	2000/03/15 18:00:49	1.56
+++ builtins.yo	2000/03/17 16:09:11
@@ -1310,7 +1310,7 @@
 )\
 ifnzman(\
 noderef(Functions)
-)
+)\
 for a description of how autoloaded functions are searched).
 
 If there is at least one var(name) argument, the wordcode for all
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Doc/Zsh/compsys.yo,v
retrieving revision 1.136
diff -u -r1.136 compsys.yo
--- compsys.yo	2000/03/15 17:56:49	1.136
+++ compsys.yo	2000/03/17 18:44:52
@@ -292,11 +292,16 @@
 )
 item()(
 The var(completer) currently active, i.e. the name of the completer
-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
+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
 ifzman(the section `Control Functions' below)\
 ifnzman(noderef(Control Functions)) 
 for more information).  
@@ -1294,6 +1299,9 @@
 It is sometimes useful to set this style for the tt(correct) or
 tt(approximate) completer so that ignored matches are prefered over
 corrections.
+
+example(zstyle ':completion:*:complete-2:*' prefer-ignored yes
+zstyle ':completion:*:(correct|approximate)-1:*' prefer-ignored yes)
 )
 item(tt(prefix-hidden))(
 This is used when matches with a common prefix are added (e.g. option

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