Re: PATCH: Re: Tags again

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > The manual says that the tags are tried `one after another'. I.e. it
> > first offers globbed-files, if that fails directories, etc. It does
> > *not* offer them all at once.
> 
> Eh?
>        tag-order

Erm... the description for the file-patterns style says what I quoted.

> ...
> 
> Are you saying this doesn't apply to files?  Or that ordering in
> file-patterns takes precedence?  Or that it's not supposed to work any more
> (and if so, how do I get tags from other sources offered at the same time,
> and why does it appear to be happening with all the various things in
> command position)?

Ok, I'll give you the longer story now...

_files (which, as you know, does the file-patterns stuff including the 
default globbed-files/directories/all-files, which is now only the
default for the file-patterns style) *is* different from other
completion functions with respect to the tags it offers. And it always 
was.

The difference is that, e.g. _command_names offers all its tags at
once because that makes sense -- you (may) want it to complete all the 
different things when you try completion in command position and you
want them now and the matches in the groups are nicely separated,
there is no overlap (ok, names may appear in more than one group, but
they still are different matches).

In _files, however, the tags represent different sub-sets of one type
of matches. You don't want to try *all* of them immediatly because
that would always give all-files.

Before my last changes to _files (at the time labels/aliases were
implemented), _tags had to use globbed-files, directories and
all-files in the default for the tag-order style. It *had* to use it
to ensure the first-globbed, then-dirs, then-all behaviour.

With the then-fixed set of tags offered by _files this was possible,
but when tags named by users (both in tag-order and in file-patterns)
became reality, this wasn't possible any more. At least not cleanly
and because of that I changed it in 10267.

Before 10267 _tags checked if the tags came from _files. If not, they
were (as the usual default behaviour) added to be tried in one go. But 
if they came from _files, the default behaviour was to make them be
tried one after another. Very ugly, as I hope you agree.

So 10267 made _files call _tags for each tag. One could still use
tag-order but there aren't many possibilities to order the one tag
offered, so... However, one could still use it with labels, of course.

One nice effect of this change is that we don't need any of the
file-tags in the default value of tag-order because, as users see it,
the file-patterns style -- including the default value for it --
already does the ordering.

Ok. The problem that finally made me implement 10267 wasn't the
ugliness in _tags, the for most callers add them together, but for
files add them separately thing. The real problem was the combination
with the possibilities of using patterns in tag-order. Consider the
settings for trying completion without a matcher and then trying it
with case-insensitive completion, defined for a specific enough
context so that you have to use the matcher style:

  zstyle ':completion:...' tag-order '*' '*:-case'
  zstyle ':completion:*:*-case' matcher 'm:{a-z}={A-Z}'

Quite simple and relies heavily on patterns, but by using them this
can be used in every context. And now think about what would happen if 
_files would offer all tags in one go. You would end up with
all-files, all-files-case behaviour (`behaviour', internally it would
even try globbed-files, directories and all-files, calling _path_files 
three times, where the last call generates all the matches added by
the first two calls).

But by making _files try the tags one after another, you get the
behaviour you want. If not you can still use the real tag names in
tag-order to form the labels you want. So here is one reason for your
next question:

> And if tag-order isn't useful with files, what's the
> point of having to name the tags (which until a few hours ago was
> compulsory)?

And the second answer: tags are not only used in tag-order as you well
know. They are (probably more importantly) used for lookup, so
allowing file-patterns to specify tags, users have the possibility to
set all the other styles that are tested for tags for the different
types of files. Maybe they want to use different patterns to ignore
for normal files and for directories. Or different matchers,
description-formats, whatever. If file-patterns wouldn't allow to
specify tags, all this wouldn't be possible.


Ok. Any questions left? ;-)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx