zsh-workers
 help / color / mirror / code / Atom feed
* _files does not list files after foo/
@ 1999-07-24 16:29 Tanaka Akira
  1999-07-27 14:07 ` Peter Stephenson
  0 siblings, 1 reply; 3+ messages in thread
From: Tanaka Akira @ 1999-07-24 16:29 UTC (permalink / raw)
  To: zsh-workers

Z(2):akr@is27e1u11% zsh -f         
is27e1u11% autoload -U compinit; compinit -D
is27e1u11% ls
ChangeLog      Doc            META-FAQ       README         acconfig.h     config.guess   config.status  install-sh
ChangeLog.3.0  Etc            Makefile       Src            aclocal.m4     config.h       config.sub     mkinstalldirs
Completion     Functions      Makefile.in    StartupFiles   aczsh.m4       config.h.in    configure      stamp-h
Config         INSTALL        Misc           Util           config.cache   config.log     configure.in   stamp-h.in
is27e1u11% gunzip ./<TAB>

After above operation, zsh does not list files in current directory.

OK, I know that the behaviour is intentional as:

_path_files:
|       # A little extra hack: if we were completing `foo/<TAB>' and `foo'
|       # contains no files, this will normally produce no matches and other
|       # completers might think that's it's their time now. But if the next
|       # completer is _correct or something like that, this will result in
|       # an attempt to correct a valid directory name. So we just add the
|       # original string in such a case so that the command line doesn't
|       # change but other completers still think there are matches.
| 
|       if [[ -z "$tpre$tsuf" && "$pre" = */ && -z "$suf" ]]; then
|         compadd -nQS '' - "$linepath$donepath$orig"
|         tmp4=-
|       fi

But it is confusing in this case.
I suppose that there should be the way to disable the hack.
-- 
Tanaka Akira


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: _files does not list files after foo/
  1999-07-24 16:29 _files does not list files after foo/ Tanaka Akira
@ 1999-07-27 14:07 ` Peter Stephenson
  0 siblings, 0 replies; 3+ messages in thread
From: Peter Stephenson @ 1999-07-27 14:07 UTC (permalink / raw)
  To: zsh-workers

Tanaka Akira wrote:
> Z(2):akr@is27e1u11% zsh -f         
> is27e1u11% autoload -U compinit; compinit -D
> is27e1u11% gunzip ./<TAB>
> 
> After above operation, zsh does not list files in current directory.
> 
> OK, I know that the behaviour is intentional as:
> 
> But it is confusing in this case.
> I suppose that there should be the way to disable the hack.

Yes, in fact in the case of something like `_files *(*)' it's preventing
the second call of _path_files from trying to look for directories when
there aren't any other matches, which is quite a serious problem (note that
it only arises right after the /, but with menu completion that's where I
mostly use completion nowadays).  This turns it off unless the path_keepdir
configuration key is set.  Maybe Sven can think of something more subtle to
do.

--- Completion/Core/_path_files.bak	Tue Jul 27 15:54:39 1999
+++ Completion/Core/_path_files	Tue Jul 27 15:54:49 1999
@@ -260,7 +260,14 @@
       # original string in such a case so that the command line doesn't 
       # change but other completers still think there are matches.
 
-      if [[ -z "$tpre$tsuf" && "$pre" = */ && -z "$suf" ]]; then
+      # Problem:  this seems to stop _files from finding directory
+      # completions if there were no file completions, for
+      # example `_files *(*)' no longer completes subdirectories after
+      # a /.  For now, make this a configuration option, but
+      # probably it needs to be done better.
+
+      if [[ -n "$compconfig[path_keepdir]" && -z "$tpre$tsuf" &&
+	"$pre" = */ && -z "$suf" ]]; then
         compadd -nQS '' - "$linepath$donepath$orig"
         tmp4=-
       fi
--- Doc/Zsh/compsys.yo.bak	Fri Jul 23 13:41:43 1999
+++ Doc/Zsh/compsys.yo	Tue Jul 27 16:00:27 1999
@@ -728,13 +728,27 @@
 `tt(-S)', `tt(-q)', `tt(-r)', and `tt(-R)' options from the
 tt(compadd) builtin.
 
-Finally, the tt(_path_files) function supports two configuration keys.
-If tt(path_expand) is set to any non-empty string, the partially
+Finally, the tt(_path_files) function supports three configuration keys.
+startitem()
+item(tt(path_expand))(
+If this is set to any non-empty string, the partially
 typed path from the line will be expanded as far as possible even if
-trailing pathname components can not be completed. And if
-tt(path_cursor) is set to a non-empty string, the cursor will be left
+trailing pathname components can not be completed.
+)
+item(tt(path_cursor))(
+If this is set to a non-empty string, the cursor will be left
 after the first ambiguous pathname component even when menucompletion
 is used.
+)
+item(tt(path_keepdir))(
+If this is set to a non-empty string, then if completion immediately after
+a slash fails, treat the original string as a successful completion.  This
+prevents a valid directory being treated as a candidate for correction.
+However, it has the side effect that a pattern completion, such as
+`tt(files -g *(*))', will no longer try to complete directories in this
+position if there are no file matches.
+)
+enditem()
 )
 item(tt(_parameters))(
 This should be used to complete parameter names if you need some of the

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: _files does not list files after foo/
@ 1999-08-02 13:40 Sven Wischnowsky
  0 siblings, 0 replies; 3+ messages in thread
From: Sven Wischnowsky @ 1999-08-02 13:40 UTC (permalink / raw)
  To: zsh-workers


Peter Stephenson wrote:

> Tanaka Akira wrote:
> > Z(2):akr@is27e1u11% zsh -f         
> > is27e1u11% autoload -U compinit; compinit -D
> > is27e1u11% gunzip ./<TAB>
> > 
> > After above operation, zsh does not list files in current directory.
> > 
> > OK, I know that the behaviour is intentional as:
> > 
> > But it is confusing in this case.
> > I suppose that there should be the way to disable the hack.
> 
> Yes, in fact in the case of something like `_files *(*)' it's preventing
> the second call of _path_files from trying to look for directories when
> there aren't any other matches, which is quite a serious problem (note that
> it only arises right after the /, but with menu completion that's where I
> mostly use completion nowadays).  This turns it off unless the path_keepdir
> configuration key is set.  Maybe Sven can think of something more subtle to
> do.

This isn't subtle at all, but I wouldn't like to have to decide
whether I want `gunzip' to work correctly or if I want to avoid this
correction-of-correct-directory-names.

So the patch below does the correction-avoidance-thingy only if
`_path_files' didn't get any of the pattern options (`-g' and `-/').

It also removes the `path_keepdir' key again -- I'm not too sure
about this. Should I put it back again? Or should we replace it by a
configuration key with the reverse meaning (and name)?

Bye
 Sven

diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Mon Aug  2 11:45:15 1999
+++ Completion/Core/_path_files	Mon Aug  2 15:35:30 1999
@@ -25,7 +25,7 @@
 
 local linepath realpath donepath prepath testpath exppath
 local tmp1 tmp2 tmp3 tmp4 i orig pre suf tpre tsuf
-local pats ignore group expl addpfx addsfx remsfx
+local pats haspats=no ignore group expl addpfx addsfx remsfx
 local nm=$compstate[nmatches] menu
 
 typeset -U prepaths exppaths
@@ -82,9 +82,11 @@
 	 ;;
   /)     sopt="${sopt}/"
          pats=("$pats[@]" '*(-/)')
+	 haspats=yes
 	 ;;
   g)     gopt='-g'
          pats=("$pats[@]" ${=OPTARG})
+	 haspats=yes
 	 ;;
   esac
 done
@@ -259,14 +261,11 @@
       # an attempt to correct a valid directory name. So we just add the
       # original string in such a case so that the command line doesn't 
       # change but other completers still think there are matches.
+      # We do this only if we weren't given a `-g' or `-/' option because
+      # otherwise this would keep `_files' from completing all filenames
+      # if none of the patterns match.
 
-      # Problem:  this seems to stop _files from finding directory
-      # completions if there were no file completions, for
-      # example `_files *(*)' no longer completes subdirectories after
-      # a /.  For now, make this a configuration option, but
-      # probably it needs to be done better.
-
-      if [[ -n "$compconfig[path_keepdir]" && -z "$tpre$tsuf" &&
+      if [[ "$haspats" = no && -z "$tpre$tsuf" &&
 	"$pre" = */ && -z "$suf" ]]; then
         compadd -nQS '' - "$linepath$donepath$orig"
         tmp4=-
diff -u od/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- od/Zsh/compsys.yo	Mon Aug  2 11:45:23 1999
+++ Doc/Zsh/compsys.yo	Mon Aug  2 15:34:30 1999
@@ -738,7 +738,7 @@
 `tt(-S)', `tt(-q)', `tt(-r)', and `tt(-R)' options from the
 tt(compadd) builtin.
 
-Finally, the tt(_path_files) function supports three configuration keys.
+Finally, the tt(_path_files) function supports two configuration keys.
 startitem()
 item(tt(path_expand))(
 If this is set to any non-empty string, the partially
@@ -749,14 +749,6 @@
 If this is set to a non-empty string, the cursor will be left
 after the first ambiguous pathname component even when menucompletion
 is used.
-)
-item(tt(path_keepdir))(
-If this is set to a non-empty string, then if completion immediately after
-a slash fails, treat the original string as a successful completion.  This
-prevents a valid directory being treated as a candidate for correction.
-However, it has the side effect that a pattern completion, such as
-`tt(files -g *(*))', will no longer try to complete directories in this
-position if there are no file matches.
 )
 enditem()
 )

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1999-08-02 13:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-24 16:29 _files does not list files after foo/ Tanaka Akira
1999-07-27 14:07 ` Peter Stephenson
1999-08-02 13:40 Sven Wischnowsky

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).