Re: _files vs _path_files discussion (old thread)

Re: _files vs _path_files discussion (old thread)

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> zstyle ':completion::complete:tar::' \
> 	tag-order 'globbed-files directories all-files'

I was about to write that this doesn't make much sense, because
all-files would generate all files, so the first two tags aren't
really needed. I wanted to add that it doesn't matter though, because
_files takes care to call _path_files only once in sucha a case. Then
I remembered file-patterns... uh oh. This `call _path_files as seldom
as possible optimisation' in _files is wrong now that we have
file-patterns, so I have to hack it anyway...


[ skipping several messages... ]

> On Mar 12,  6:21am, Bart Schaefer wrote:
> } Subject: Re: _files vs _path_files discussion (old thread)
> }
> } [*] Sven's suggested change was:
> } } ... should we make the directories tag with its usual pattern be
> } } tried automatically if the user explicitly sets the file-patterns tag
> } } for globbed-files? Or should we do that only if the directories tag,
> } } file-patterns style is given, but allow an empty value to stand for
> } } `the normal pattern'?
> } 
> } My short answer is that I don't think there's any good solution.  The
> } tag-order style is going to be confusing no matter what we do [...]
> 
> One additional thought:  It would be nice to be able to specify that
> _paths_ are completed, rather than merely directories; i.e. like the
> difference between "compctl -g '*(-/)'" and "compctl -/".  I'm not
> convinced that "zstyle *directories file-patterns '*(-/)'" does that.

Actually, I thought that _path_files makes it behave like `compctl -/',
where do you see a difference?

Oh, and `*(-/)' is the pattern used by _path_files if given the -/
option.

> } some kind of blaring all-caps text in the tag-order documentation:
> } 
> } NAMING A TAG IN TAG-ORDER DOES NOT CAUSE COMPLETIONS FOR THAT TAG TO BE
> } GENERATED; RATHER, IT SORTS THE COMPLETIONS AFTER THEY ARE GENERATED.
> 
> Hrm, maybe even add "... BUT ONLY _IF_ ANY ARE GENERATED FOR THAT TAG."

Yep.


[ skipping even more messages... ]

> Effectively, what you want is to subdivide the 'directories' tag and
> have it treated like it has it's own internal tag-order.  There isn't
> any way I can think of to express that at the moment.
> 
> One possibility would be to make file-patterns itself into a hierarchy;
> that is
> 
> zstyle :completion::complete:tar::directories \
> 	file-patterns '*(-/)' '.*(-/)'
> 
> would mean to use '.*(-/)' only if '*(-/)' returned nothing.  The current
> meaning of the above is also expressible by
> 
> zstyle :completion::complete:tar::directories \
>         file-patterns '*(-/) .*(-/)'
> 
> (that is, file-patterns is presently a string, not an array) so we would
> not be losing any functionality.

Nice idea. And doesn't sound too hard to implement...

> Then all we need is a magic token in file-patterns to mean "use anything
> passed to _files with the -g option here" and global file-patterns would
> become really useful.

Maybe we could just use an empty string as the magic token, it's used
elsewhere already.

First question: should the magic token only be used for -g or also for
-/ (i.e. should it mean: `the glob-pattern from the caller' or `the
files selected by the caller').

Much more dramatic second question: should we get rid of globbed-files,
directories, all-files?

I mean: if we change the file-patterns style as suggested, then a call 
to _files with, say, -g '*.ps' has the same effect as using

  file-patterns == '*.ps' '*(-/)' '*'

Allowing multiple patterns in file-patterns and still using multiple
tags doesn't add much to functionality, but adds a lot to obscurity, I 
think. The only thing missing is that there aren't different tags
used, which could otherwise be used by style patterns. But 1)
sometimes these different tags are a bit in the way, e.g. when setting 
ignored-patterns and 2) it would be easy to enhance the syntax for
file-patterns to include (dreamed up) names of tags. 

  file-patterns == 'globbed-files:*.ps' 'directories:*(-/)' ...

or something like that.

Hm... _files would take its arguments to get a set of patterns to
try. Then it looks at the file-patterns style, using the `files'
tag. If that is set, only those patterns are used, unless there is the 
magic token which means `insert the special supplied pattern here, if
there is any'. And then it calls _path_files for the patterns until
one generates matches. Either always using the files tag or the tags
given in the file-patterns value (if we implement that; should the
standard patterns automatically derived from the arguments of _files
use the tags we use now, then?).

Changing _files this way would make it much easier (and better
readable and hence easier to modify), obviously. But it would mean
that users would have to fiddle with glob patterns instead of only
tags in this case -- I'm never sure, what is considered too
inconvenient: is this onme of those cases?

Bye
 Sven


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

Re: _files vs _path_files discussion (old thread)

[Bart Schaefer]

On Mar 13,  2:07pm, Sven Wischnowsky wrote:
} Subject: Re: _files vs _path_files discussion (old thread)
}
} Bart Schaefer wrote:
} > One additional thought:  It would be nice to be able to specify that
} > _paths_ are completed, rather than merely directories; i.e. like the
} > difference between "compctl -g '*(-/)'" and "compctl -/".  I'm not
} > convinced that "zstyle *directories file-patterns '*(-/)'" does that.
} 
} Actually, I thought that _path_files makes it behave like `compctl -/',
} where do you see a difference?

I don't, actually ... so probably there isn't any.

} > One possibility would be to make file-patterns itself into a hierarchy;
} 
} Nice idea. And doesn't sound too hard to implement...
} 
} > Then all we need is a magic token in file-patterns to mean "use anything
} > passed to _files with the -g option here" and global file-patterns would
} > become really useful.
} 
} Maybe we could just use an empty string as the magic token, it's used
} elsewhere already.
} 
} First question: should the magic token only be used for -g or also for
} -/ (i.e. should it mean: `the glob-pattern from the caller' or `the
} files selected by the caller').

It should mean the files selected by the caller.
 
} Much more dramatic second question: should we get rid of globbed-files,
} directories, all-files?

The problem with getting rid of them is that e.g. _cvs uses 'directories'
to mean something different than '*(-/)' (in effect, to omit the CVS/
subdir and any subdir that doesn't contain a CVS/ subdir).  It's useful
to be able to define "directories" independently of other glob tags.

(Of course, _cvs and its helpers don't test the file-patterns or call
_files, they use compadd directly.  So it's not quite the same issue,
but it could still come up.)
 
} Allowing multiple patterns in file-patterns and still using multiple
} tags doesn't add much to functionality, but adds a lot to obscurity, I 
} think.

Perhaps.

}   file-patterns == 'globbed-files:*.ps' 'directories:*(-/)' ...
} 
} or something like that.

That might cover it, though I dislike putting the tag name in the same
word as the pattern.  We already have too many strings that have to be
split into substrings before interpreting, as far as I'm concerned.

} [...] And then [_files] calls _path_files for the patterns until
} one generates matches. Either always using the files tag or the tags
} given in the file-patterns value (if we implement that; should the
} standard patterns automatically derived from the arguments of _files
} use the tags we use now, then?).

I don't understand the question, I fear.

} Changing _files this way would make it much easier (and better
} readable and hence easier to modify), obviously.

I'm all in favor of that ...

} But it would mean that users would have to fiddle with glob patterns
} instead of only tags in this case -- I'm never sure, what is
} considered too inconvenient: is this onme of those cases?

I don't think users fiddling with glob patterns is a problem; it's not
much by comparison with figuring out style context names in the first
place.  I'm more concerned about what the completion functions do in
cases like the _cvs example I mentioned above.

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

Re: _files vs _path_files discussion (old thread)

[Bart Schaefer]

On Mar 12,  8:14pm, Adam Spiers wrote:
} Subject: Re: _files vs _path_files discussion (old thread)
}
} > If you have global directories file-patterns you're going to need them
} > for globbed-files, too ...
} 
} Why's that?  I'm still not fully understanding this, it seems.

The default for _files with no options and no file-patterns styles is to
use the all-files tag (this is determined by the setting of `type' in
_files if you want to follow it).

If you give file-patterns for any of globbed-files, directories or
all-files, then (`type' gets changed, so) different tags are used.  If
the only file-patterns you give are for directories, then the tags used
are directories and all-files.

To get globbed-files used, you either have to specify file-patterns for
it, or else the caller of _files has to pass -g.

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

Re: _files vs _path_files discussion (old thread)

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> On Mar 12,  1:02pm, Adam Spiers wrote:
> } Subject: Re: _files vs _path_files discussion (old thread)
> }
> }    # Include non-hidden directories in globbed file completions
> }    compstyle '::complete:*' \
> }      tag-order 'globbed-files directories' all-files 
> }    compstyle '::complete:*:*:directories' file-patterns '*~.*(-/)'
> } 
> } It's almost perfect ...
> 
> Have you tried that with, say, `ls' ?  I'll bet it ends up completing
> _only_ directories, because there's no -g option passed to _files for
> `ls' like there is for `tar'.

Of course you're right, and I had to change it back as soon as I
realised :-(

> If you have global directories file-patterns you're going to need them
> for globbed-files, too ...

Why's that?  I'm still not fully understanding this, it seems.

> Do you have the GLOB_DOTS option set, by chance?

I did, until you pointed it out ;-)

> Effectively, what you want is to subdivide the 'directories' tag and
> have it treated like it has it's own internal tag-order.

That's right.  Now why couldn't I have thought clearly enough to
realise that?

> One possibility would be to make file-patterns itself into a hierarchy;
> that is
> 
> zstyle :completion::complete:tar::directories \
> 	file-patterns '*(-/)' '.*(-/)'
> 
> would mean to use '.*(-/)' only if '*(-/)' returned nothing.  The current
> meaning of the above is also expressible by
> 
> zstyle :completion::complete:tar::directories \
>         file-patterns '*(-/) .*(-/)'
> 
> (that is, file-patterns is presently a string, not an array) so we would
> not be losing any functionality.
> 
> Then all we need is a magic token in file-patterns to mean "use anything
> passed to _files with the -g option here" and global file-patterns would
> become really useful.

That sounds really nice.

Re: _files vs _path_files discussion (old thread)

[Bart Schaefer]

On Mar 12,  1:02pm, Adam Spiers wrote:
} Subject: Re: _files vs _path_files discussion (old thread)
}
}    # Include non-hidden directories in globbed file completions
}    compstyle '::complete:*' \
}      tag-order 'globbed-files directories' all-files 
}    compstyle '::complete:*:*:directories' file-patterns '*~.*(-/)'
} 
} It's almost perfect ...

Have you tried that with, say, `ls' ?  I'll bet it ends up completing
_only_ directories, because there's no -g option passed to _files for
`ls' like there is for `tar'.

If you have global directories file-patterns you're going to need them
for globbed-files, too ... which then messes up things like `tar' that
pass patterns with -g.  The globbed-files style replaces the -g option
of _files.

} The only problem left is in the handling of
} hidden directories; ideally, I would want hidden directories only to
} appear when the leading `.' is specified manually

Hrm, the behavior you want is the behavior I get (for tar), by using:

zstyle ':completion::complete:tar::directories' file-patterns '*(-/)'

Do you have the GLOB_DOTS option set, by chance?

}    zstyle ':completion::complete:*:*:directories' \
}      file-patterns '*(-/)'
}    zstyle ':completion::complete:*:*:unhidden-directories' \
}      file-patterns '*~.*(-/)'
}    zstyle ':completion::complete:*' tag-order \
}      'globbed-files unhidden-directories' \
}      'globbed-files directories' \
}      all-files
} 
} except that that doesn't work, presumably because you can't just dream
} up new tags like that

You can dream up new tags, but they'll only be used by functions that
know about them -- so you'd have to e.g. modify _files as well.

} and maybe you can't even mention tags twice in tag-order.

It doesn't make sense to mention tags twice in tag-order, because (in
your example) 'globbed-files directories' will only be used when there
are no completions for 'globbed-files unhidden-directories', which 
can't happen if there are any completions for globbed-files alone.

Effectively, what you want is to subdivide the 'directories' tag and
have it treated like it has it's own internal tag-order.  There isn't
any way I can think of to express that at the moment.

One possibility would be to make file-patterns itself into a hierarchy;
that is

zstyle :completion::complete:tar::directories \
	file-patterns '*(-/)' '.*(-/)'

would mean to use '.*(-/)' only if '*(-/)' returned nothing.  The current
meaning of the above is also expressible by

zstyle :completion::complete:tar::directories \
        file-patterns '*(-/) .*(-/)'

(that is, file-patterns is presently a string, not an array) so we would
not be losing any functionality.

Then all we need is a magic token in file-patterns to mean "use anything
passed to _files with the -g option here" and global file-patterns would
become really useful.

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

Re: _files vs _path_files discussion (old thread)

[Adam Spiers]

Thanks for these explanations Bart, and apologies for missing the
thread the first time round.

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> So you also need e.g.:
> 
> zstyle ':completion::complete:tar::directories' file-patterns '*(-/)'
> 
> You can of course replace :tar:: there with :*:*: to make all commands
> that use _files complete directories; but as Sven mentions in 9864,
> you may not want that, which is why the file-patterns are required to
> be given in the first place.

I've settled on the following for now, and it doesn't seem to have any
of the unwanted side-effects mentioned:

   # Include non-hidden directories in globbed file completions
   compstyle '::complete:*' \
     tag-order 'globbed-files directories' all-files 
   compstyle '::complete:*:*:directories' file-patterns '*~.*(-/)'

It's almost perfect ...  The only problem left is in the handling of
hidden directories; ideally, I would want hidden directories only to
appear when the leading `.' is specified manually, because I have so
many hidden directories in my home directory that they swamp the
initial completion list.  However, because they are not covered by the
file-patterns style for the directories tag, if I do:

   $ tar zxf .foodir/<TAB>

it's presumably using all-files, which has the initial problem of not
listing directories by default.  So what I'm really after is something
like:

   zstyle ':completion::complete:*:*:directories' \
     file-patterns '*(-/)'
   zstyle ':completion::complete:*:*:unhidden-directories' \
     file-patterns '*~.*(-/)'
   zstyle ':completion::complete:*' tag-order \
     'globbed-files unhidden-directories' \
     'globbed-files directories' \
     all-files

except that that doesn't work, presumably because you can't just dream
up new tags like that, and maybe you can't even mention tags twice in
tag-order.  So, is there a solution, and if not, would it be totally
unrealistic to allow something like the above zstyle code?  Actually,
even if that code worked, it still wouldn't quite do what I want,
because at the `.foodir/<TAB>' stage it would be completing from the
'globbed-files directories' bit (or would it?), which would mean that
it would list `.foodir/.bardir', which I wouldn't want it to.  Looks
like what I'm asking for would require considering each path component
separately.  Urgh.  Now my head's spinning.

> [*] Sven's suggested change was:
> } ... should we make the directories tag with its usual pattern be
> } tried automatically if the user explicitly sets the file-patterns tag
> } for globbed-files? Or should we do that only if the directories tag,
> } file-patterns style is given, but allow an empty value to stand for
> } `the normal pattern'?
> 
> I meant to reply to that and hadn't got around to it yet.
> 
> My short answer is that I don't think there's any good solution.  The
> tag-order style is going to be confusing no matter what we do; people
> are always going to wonder why, when they can see "directories" in the
> tag-order style, they still don't get any directories completed.  It's
> a case of intuition being at odds with logical semantics, and I can't
> think of any way to make the intuition work without ruining the logic.
> 
> Automatically adding directories when globbed-files is given only makes
> things cloudier; allowing an empty pattern to stand for '*(-/)' doesn't
> alleviate the need to provide the directories style, which is the real
> basis of the confusion.  So I think I'd leave the code as is, and put
> some kind of blaring all-caps text in the tag-order documentation:
> 
> NAMING A TAG IN TAG-ORDER DOES NOT CAUSE COMPLETIONS FOR THAT TAG TO BE
> GENERATED; RATHER, IT SORTS THE COMPLETIONS AFTER THEY ARE GENERATED.

I'd agree.  Actually, now I know the stuff in blaring all-caps, I
don't find it that confusing anyway.

> One additional thought:  It would be nice to be able to specify that
> _paths_ are completed, rather than merely directories; i.e. like the
> difference between "compctl -g '*(-/)'" and "compctl -/".  I'm not
> convinced that "zstyle *directories file-patterns '*(-/)'" does that.

What is the difference?  I can't see any, but I'm probably missing
something (again).

> Hrm, maybe even add "... BUT ONLY _IF_ ANY ARE GENERATED FOR THAT TAG."

Good plan.

Adam

Re: _files vs _path_files discussion (old thread)

[Bart Schaefer]

On Mar 12,  6:21am, Bart Schaefer wrote:
} Subject: Re: _files vs _path_files discussion (old thread)
}
} [*] Sven's suggested change was:
} } ... should we make the directories tag with its usual pattern be
} } tried automatically if the user explicitly sets the file-patterns tag
} } for globbed-files? Or should we do that only if the directories tag,
} } file-patterns style is given, but allow an empty value to stand for
} } `the normal pattern'?
} 
} My short answer is that I don't think there's any good solution.  The
} tag-order style is going to be confusing no matter what we do [...]

One additional thought:  It would be nice to be able to specify that
_paths_ are completed, rather than merely directories; i.e. like the
difference between "compctl -g '*(-/)'" and "compctl -/".  I'm not
convinced that "zstyle *directories file-patterns '*(-/)'" does that.

} some kind of blaring all-caps text in the tag-order documentation:
} 
} NAMING A TAG IN TAG-ORDER DOES NOT CAUSE COMPLETIONS FOR THAT TAG TO BE
} GENERATED; RATHER, IT SORTS THE COMPLETIONS AFTER THEY ARE GENERATED.

Hrm, maybe even add "... BUT ONLY _IF_ ANY ARE GENERATED FOR THAT TAG."

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

Re: _files vs _path_files discussion (old thread)

[Bart Schaefer]

On Mar 12, 12:51am, Adam Spiers wrote:
} Subject: Re: _files vs _path_files discussion (old thread)
}
} Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
} > zstyle ':completion::complete:tar::' \
} > 	tag-order 'globbed-files directories' all-files
} 
} That's exactly what I'd tried, with once difference; as I mentioned, I
} want this behaviour everywhere, not just for tar, so I'd tried:
} 
} zstyle ':completion::complete:*' \
}   tag-order 'globbed-files directories' all-files
} 
} However, neither your version nor mine seem to work.  Maybe I'm just
} missing a bugfix because I'm behind on patches.

No; Sven explained this back in 9858, and asked whether it should be
changed [*].  It's not sufficient to give the tag-order style, you
also have to specify the file-patterns for each of the tags that you
actually want to generate completions.  So you also need e.g.:

zstyle ':completion::complete:tar::directories' file-patterns '*(-/)'

You can of course replace :tar:: there with :*:*: to make all commands
that use _files complete directories; but as Sven mentions in 9864,
you may not want that, which is why the file-patterns are required to
be given in the first place.

_tar already supplies a file pattern for globbed-files by passing a -g
option to _files, so (unlike many other commands) you _don't_ need to
specify the file-patterns for *:tar::globbed-files.  You _do_ need to
specify file-patterns for all-files if you want those included.

[*] Sven's suggested change was:
} ... should we make the directories tag with its usual pattern be
} tried automatically if the user explicitly sets the file-patterns tag
} for globbed-files? Or should we do that only if the directories tag,
} file-patterns style is given, but allow an empty value to stand for
} `the normal pattern'?

I meant to reply to that and hadn't got around to it yet.

My short answer is that I don't think there's any good solution.  The
tag-order style is going to be confusing no matter what we do; people
are always going to wonder why, when they can see "directories" in the
tag-order style, they still don't get any directories completed.  It's
a case of intuition being at odds with logical semantics, and I can't
think of any way to make the intuition work without ruining the logic.

Automatically adding directories when globbed-files is given only makes
things cloudier; allowing an empty pattern to stand for '*(-/)' doesn't
alleviate the need to provide the directories style, which is the real
basis of the confusion.  So I think I'd leave the code as is, and put
some kind of blaring all-caps text in the tag-order documentation:

NAMING A TAG IN TAG-ORDER DOES NOT CAUSE COMPLETIONS FOR THAT TAG TO BE
GENERATED; RATHER, IT SORTS THE COMPLETIONS AFTER THEY ARE GENERATED.

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

Re: _files vs _path_files discussion (old thread)

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> On Mar 11, 10:22pm, Adam Spiers wrote:
> } Subject: Re: _files vs _path_files discussion (old thread)
> }
> } > > A second issue is whether, if you find target files in the current
> } > > directory, you might still want to complete directories.
> } 
> } Does the new zstyle stuff now provide some kind of configurability to
> } solve this issue?
> 
> Yes, it's the tag-order style.

Ah, so I was right after all.

> By putting all the tags in the same argument, they're all treated as
> equal for purposes of completions.  You could also do
> 
> zstyle ':completion::complete:tar::' \
> 	tag-order 'globbed-files directories' all-files

That's exactly what I'd tried, with once difference; as I mentioned, I
want this behaviour everywhere, not just for tar, so I'd tried:

zstyle ':completion::complete:*' \
  tag-order 'globbed-files directories' all-files

However, neither your version nor mine seem to work.  Maybe I'm just
missing a bugfix because I'm behind on patches.

Adam

Re: _files vs _path_files discussion (old thread)

[Bart Schaefer]

On Mar 11, 10:22pm, Adam Spiers wrote:
} Subject: Re: _files vs _path_files discussion (old thread)
}
} > > A second issue is whether, if you find target files in the current
} > > directory, you might still want to complete directories.
} 
} Does the new zstyle stuff now provide some kind of configurability to
} solve this issue?

Yes, it's the tag-order style.

} Suppose I have, in the cwd, a file `foo.tar.gz' and a directory `foo'.
} I type:
} 
}   $ tar zxf foo<TAB>
} 
} Currently, this immediately completes to `foo.tar.gz'.  But what if I
} actually wanted to extract a .tar.gz from somewhere within the
} directory foo?

zstyle ':completion::complete:tar::' \
	tag-order 'globbed-files directories all-files'

By putting all the tags in the same argument, they're all treated as
equal for purposes of completions.  You could also do

zstyle ':completion::complete:tar::' \
	tag-order 'globbed-files directories' all-files

(that is, put all-files in a separate argument) to get shown all possible
files only if there are no globbed-files or directories.  The default is
as if you had

zstyle ':completion::complete:tar::' \
	tag-order globbed-files directories all-files

(that is, all in separate arguments), which in turn depends on some of
the command-line options passed to _files by _tar (so it's not the same
for all completions that use _files).

} Incidentally, the more I understand of the new completion system, the
} more I like it.  [...]  Congratulations to everyone involved,
} especially (needless to say) Sven!

Right, three cheers for Sven!  And thanks.

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

Re: _files vs _path_files discussion (old thread)

[Adam Spiers]

[digging up a very old thread]

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> 
> Peter Stephenson wrote:
> 
> > Adam Spiers wrote:
> > > Now people may disagree with this, but I would have thought that in
> > > many completion scenarios, _path_files -/ -g <glob> is more
> > > appropriate than _files -g <glob>.  For example, when completing tar
> > > archives, if there are none in directory foo, and you type 
> > 
> > ...
> > 
> > A second issue is whether, if you find target files in the current
> > directory, you might still want to complete directories.  This is also hard
> > to generalise on, since if you are completing a common enough file type you
> > might very well want to be offered directories straight away, while if
> > there aren't many of that type they may just get in the way.  But probably
> > we need to be more consistent, rather than depending on who happened to
> > write the completion file.

Does the new zstyle stuff now provide some kind of configurability to
solve this issue?  Here's a practical example of the issue, just to
make sure it's clear what I'm talking about:

Suppose I have, in the cwd, a file `foo.tar.gz' and a directory `foo'.
I type:

  $ tar zxf foo<TAB>

Currently, this immediately completes to `foo.tar.gz'.  But what if I
actually wanted to extract a .tar.gz from somewhere within the
directory foo?  According to _complete_help, _tar calls _tar_archive,
which calls _files, which generates the tags `globbed-files',
`directories', and `all-files'.

Presumably because some globbed-files were found, directories were not
added to the list of completions.  Is it possible to set some style
appropriately so that directories are listed immediately along with
tarballs?  I'm interested in a general solution which would apply to
all invocations of `_files -g ...'.

Incidentally, the more I understand of the new completion system, the
more I like it.  Sure, it's very intricate and takes a lot of getting
used to, but it seems to me that the various concepts have been
abstracted out in just the right way so as to allow completion
function writers maximum flexibility and convenience.  It's also great
that the end-user can just press TAB and instantly enjoy all this
power without worrying about how it works, and that there is so much
configurability available from zstyle.  Congratulations to everyone
involved, especially (needless to say) Sven!

Adam