Re: PATCH: _rpm tweaks (_files vs _path_files discussion)

Re: PATCH: _rpm tweaks (_files vs _path_files discussion)

[Sven Wischnowsky]

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.

That's certainly right. I was worried about all these `-g' things I
added, too, and only thought about adding a config key that would be
used in all those places where we now use `-g'. I didn't think about:

> It's not a perfect solution, but we could have an argument to _files saying
> search only for directories if nothing found, not everything else, and a
> completion key saying whether, if that flag is passed, you want directories
> included in the list with the other files.  For example,
> _files -g <glob> + -/ (hey, this gives me the idea for another type of
> completion interface :-/), and the configuration option
> path_merge_alternatives, or something shorter.

This sounds good.

Bye
 Sven


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

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

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]

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

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

[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,  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]

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

PATCH: _rpm tweaks (_files vs _path_files discussion)

[Adam Spiers]

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 

  % tar zxf foo/<TAB>

getting a list of all files in the directory is fairly undesirable,
no?

Another case is completing *.spec and *.rpm files with _rpm, which
irritated me enough to provide a patch :-)

It's a matter of taste I suppose, but I'd be interested to hear
whether I'm alone on this.

Index: Completion/Linux/_rpm
diff -u Completion/Linux/_rpm:1.1.1.2 Completion/Linux/_rpm:1.2
--- Completion/Linux/_rpm:1.1.1.2	Thu Sep 16 12:39:44 1999
+++ Completion/Linux/_rpm	Thu Sep 16 13:00:22 1999
@@ -148,7 +148,7 @@
       '*:RPM package:->package' && ret=0
     ;;
   build_b)
-    tmp=( '*:spec file:_files -g \*.spec' )
+    tmp=( '*:spec file:_path_files -/ -g \*.spec' )
     ;&
   build_t)
     (( $#tmp )) || tmp=( '*:tar file:_files -g \*.\(\#i\)tar\(.\*\|\)' )
@@ -195,7 +195,7 @@
       _hosts -S/ && ret=0
     else
       _description expl 'RPM package file'
-      _files "$expl[@]" -g '*.(#i)rpm' && ret=0
+      _path_files "$expl[@]" -/ -g '*.(#i)rpm' && ret=0
       _description expl 'ftp URL prefix'
       compadd "$expl[@]" ftp://
     fi

Re: PATCH: _rpm tweaks (_files vs _path_files discussion)

[Peter Stephenson]

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 

It is a bit of a problem.  The real trouble is _files is too generic; if it
fails, it doesn't know what it should try next.  Often, as in this case, it
should try directories, but sometimes, for example looking for tar archives
with a non-standard suffix, it's useful to get everything.  This depends
on where you are completing.

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.

It's not a perfect solution, but we could have an argument to _files saying
search only for directories if nothing found, not everything else, and a
completion key saying whether, if that flag is passed, you want directories
included in the list with the other files.  For example,
_files -g <glob> + -/ (hey, this gives me the idea for another type of
completion interface :-/), and the configuration option
path_merge_alternatives, or something shorter.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy