Re: PATCH: Re: Tags again

Re: PATCH: Re: Tags again

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sven Wischnowsky wrote:
> > Ok. Any questions left? ;-)
> 
> Thanks for the explanation.  I've upgraded my remarks in the user guide
> (which actually already gave half the story) to say `don't use tag-order
> with files'.
> 
> I was still struck by one slight hickup:  I expected to be able to say
> '*.lst:globbed-files *(-/):directories' to get them named differently but
> called at the same time, but it seems you have to do
> '*.lst *(-/):globbed-files' which kind of defeats the object of giving them
> a name.  But maybe I've missed something again.

I'm don't think it makes the name useless, but... hey, I hadn't
thought of this multiple names in one string thing. Makes it look more 
like tag-order which is almost certainly a good thing.

One small problem: we always supported (in file-patterns and in the
argument to -g) multiple patterns separated by white space. If we find 
an acceptable syntax for this combined with the multiple-names thing,
I'll implement it. Using backslashes before the spaces would be the
wrong thing, though -- that's already used to include spaces in the
patterns.


Bye
 Sven


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

Re: PATCH: Re: Tags again

[Sven Wischnowsky]

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

Re: PATCH: Re: Tags again

[Peter Stephenson]

Sven Wischnowsky wrote:
> Ok. Any questions left? ;-)

Thanks for the explanation.  I've upgraded my remarks in the user guide
(which actually already gave half the story) to say `don't use tag-order
with files'.

I was still struck by one slight hickup:  I expected to be able to say
'*.lst:globbed-files *(-/):directories' to get them named differently but
called at the same time, but it seems you have to do
'*.lst *(-/):globbed-files' which kind of defeats the object of giving them
a name.  But maybe I've missed something again.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

PATCH: Re: Tags again

[Sven Wischnowsky]

Peter Stephenson wrote:

> I've got to stop using zsh's productivity-enhancing features at work, it's
> ruining my productivity...
> 
> What am I doing wrong this time?  I want a script `asrcs' to complete *.lst
> files and directories.  So I set up:
> 
> zstyle ':completion:*:*:asrcs:*:*' file-patterns '*.lst:globbed-files' \
>   '*(-/):directories'  '*:all-files'
> zstyle ':completion:*:*:asrcs:*:*' tag-order 'globbed-files directories' \
>   all-files
> 
> (Note that asrcs is just using default, i.e. file, completion.)  I was
> expecting this to complete globbed files and directories with equal
> priority.  But it doesn't; it just completes the globbed files unless there
> aren't any, then directories.  If I change the order in the file-patterns so
> that directories are first, it uses them instead.  So tag-order doesn't
> seem to be working as I expect --- if that wasn't there, though, this would
> be pretty much the behaviour I would expect.  Am I expecting wrong?  The
> documentation tends to support my expectations (I'll look through the
> documentation nearer the release, but it's a massive job so I don't want
> to have to do it more than once).

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.

I changed it to that in 10267. The main reason was the pattern-tag
stuff in tag-order. A `*' would have matched all tags, giving everyone 
the all-files behaviour on the first attempt. Also, file-patterns
already allows ordering, no need for a second way to order the tags
(and it may be confusing if done accidentally).

So, what you want is just:

  zstyle ':completion:*:*:asrcs:*:*' file-patterns '*.lst *(-/):globbed-files' \
                                                   '*:all-files'

No fiddling with tag-order needed.

> By the way, although that part seems to be working just as documented, it
> might be nice to allow file-patterns to have a default tag, such as
> `files', so that `*.lst' on its own would be interpreted as `*.lst:files'.
> It's a little confusing if you miss out the tag part at present: stuff just

Yes, that's sensible...

Bye
 Sven

Index: Completion/Core/_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Core/_files,v
retrieving revision 1.4
diff -u -r1.4 _files
--- Completion/Core/_files	2000/04/05 10:50:08	1.4
+++ Completion/Core/_files	2000/04/06 11:25:53
@@ -1,6 +1,6 @@
 #autoload
 
-local opts tmp glob pats expl tag i pat descr end ign ret=1
+local opts tmp glob pat pats expl tag i def descr end ign ret=1
 
 zparseopts -a opts \
     '/=tmp' 'f=tmp' 'g+:-=tmp' q n 1 2 P: S: r: R: W: X+: M+: F: J+: V+:
@@ -19,9 +19,16 @@
   ign=
 fi
 
-if zstyle -a ":completion:${curcontext}:" file-patterns pats; then
+if zstyle -a ":completion:${curcontext}:" file-patterns tmp; then
   [[ "$type" = */* ]] && glob="$glob *(-/)"
-  pats=( \ ${(M)^${pats//\\%p/ ${glob:-\*} }:#*[^\\]:*} )
+  pats=()
+  for i in ${tmp//\\%p/ ${${glob:-\*}//:/\\:} }; do
+    if [[ $i = *[^\\]:* ]]; then
+      pats=( "$pats[@]" " $i" )
+    else
+      pats=( "$pats[@]" " ${i}:files" )
+    fi
+  done
 else
   if [[ "$type" = *g* ]]; then
     if [[ "$type" = */* ]]; then
@@ -37,14 +44,14 @@
   fi
 fi
 
-for tag in "${(@)${(@)pats#*[^\\]:}%%:*}"; do
+for def in "$pats[@]"; do ###"${(@)${(@)pats#*[^\\]:}%%:*}"; do
 
-  i="$pats[(I)*[^\\\\]:${tag}(|:*)]"
-  pat="${${pats[i]%%:${tag}*}//\\\\:/:}"
+  tag="${${def#*[^\\]:}%%:*}"
+  pat="${${def%%:${tag}*}//\\\\:/:}"
 
-  if [[ i -gt 0 && "$pat" != \ # ]]; then
-    if [[ "$pats[i]" = *:${tag}:* ]]; then
-      descr="${pats[i]#*:${tag}:}"
+  if [[ "$pat" != \ # ]]; then
+    if [[ "$def" = *:${tag}:* ]]; then
+      descr="${def#*:${tag}:}"
     else
       descr=file
       end=yes
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.9
diff -u -r1.9 compsys.yo
--- Doc/Zsh/compsys.yo	2000/04/05 19:29:15	1.9
+++ Doc/Zsh/compsys.yo	2000/04/06 11:25:57
@@ -942,7 +942,8 @@
 Colons in the pattern have to be preceded by a backslash to
 make them distinguishable from the colon before the var(tag). The
 var(tag)s of all strings in the value will be offered by tt(_files)
-(again, one after another) and used when looking up other styles. The
+(again, one after another) and used when looking up other styles. If
+no `tt(:)var(tag)' is given the tt(files) tag will be used. The
 var(tag) may also be
 followed by an optional second colon and a description. If that is
 given, this description will be used for the `tt(%d)' in the value of

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

Re: PATCH: Re: Tags again

[Peter Stephenson]

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
              This  provides a mechanism for sorting how the tags
              available in a particular context will be used.



zsh 3.1.6-dev-21          April 2, 2000                        29





ZSHCOMPSYS(1)                                       ZSHCOMPSYS(1)


              The values for the style are  sets  of  space-sepa-
              rated  lists  of tags.  The tags in each value will
              be tried at the same time; if no  match  is  found,
              the next value is used.

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

Now I'm immensely confused.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk