Re: file completion bug

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> Something weird is going on, presumably after some recent change to
> _path_files.
> 
> With zsh -f, completion loaded, and compconfig[completer] set to
> _complete:_correct ,
> 
> % echo ~/tmp/d1/<TAB>
> 
> goes to
> 
> % echo ~/tmp/RCS//
> 
> and offers corrections in tmp.  But tmp/d1 exists; I don't want to alter
> the directory I'm completing in just because it's empty.

It's been there for quite some time and it was intentional. The
important bit is the trailing slash: with that _path_files wants to
complete in that directory, of course -- and can't add any matches
because there aren't any. Then _correct takes over.

However, this already irritated me too, I just forgot to have a look
at it. The patch below is somewhat radical: it looks if we have such a 
slash-terminated string on the line and if there are no matches in
that directory, it adds the original string as a `match', thus keeping 
other completers from adding more matches or whatever.

Bye
 Sven

diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Wed Jul 14 14:47:03 1999
+++ Completion/Core/_path_files	Wed Jul 14 15:32:43 1999
@@ -252,6 +252,18 @@
         continue 2
       fi
     elif (( ! $#tmp1 )); then
+      # 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
       continue 2
     fi
 

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx