PATCH: _rpm tweaks (_files vs _path_files discussion)

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

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