Re: file completion bug

Re: file completion bug

[Peter Stephenson]

Sven Wischnowsky wrote:
> 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.

Sounds good, but why when I type ^D does the cursor move down one line and
stay there in this case (i.e. existing empty directory)?  Happens with a
completely vanilla completion setup.

-- 
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: file completion bug

[Sven Wischnowsky]

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@informatik.hu-berlin.de

Re: file completion bug

[Sven Wischnowsky]

Peter Stephenson wrote:

> Sounds good, but why when I type ^D does the cursor move down one line and
> stay there in this case (i.e. existing empty directory)?  Happens with a
> completely vanilla completion setup.

Because the listmatches() functions got really confused if they had to 
list a list with only hidden matches (they did their trashzle() and at
the end thought they had to print a newline).

Bye
 Sven

diff -u os/Zle/complist.c Src/Zle/complist.c
--- os/Zle/complist.c	Wed Jul 14 10:41:24 1999
+++ Src/Zle/complist.c	Wed Jul 14 16:03:41 1999
@@ -318,15 +318,6 @@
     }
     getcols(&col);
 
-    /* Set the cursor below the prompt. */
-    if (inselect)
-	clearflag = 0;
-    trashzle();
-    showinglist = listshown = 0;
-
-    clearflag = (isset(USEZLE) && !termflags &&
-		 complastprompt && *complastprompt);
-
     for (g = amatches; g; g = g->next) {
 	char **pp = g->ylist;
 	int nl = 0, l;
@@ -403,6 +394,18 @@
 			nlines += 1 + ((1 + niceztrlen(m->str)) / columns);
 	}
     }
+    if (!nlines) {
+	showinglist = listshown = 0;
+	return 1;
+    }
+    /* Set the cursor below the prompt. */
+    if (inselect)
+	clearflag = 0;
+    trashzle();
+    showinglist = listshown = 0;
+
+    clearflag = (isset(USEZLE) && !termflags &&
+		 complastprompt && *complastprompt);
 
     /* Maybe we have to ask if the user wants to see the list. */
     if ((!minfo.cur || !minfo.asked) &&
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Wed Jul 14 13:46:56 1999
+++ Src/Zle/zle_tricky.c	Wed Jul 14 16:03:58 1999
@@ -7949,13 +7949,6 @@
     int nlines = 0, ncols, nlist = 0, longest = 1, pnl = 0;
     int of = isset(LISTTYPES), opl = 0;
 
-    /* Set the cursor below the prompt. */
-    trashzle();
-    showinglist = listshown = 0;
-
-    clearflag = (isset(USEZLE) && !termflags &&
-		 complastprompt && *complastprompt);
-
     for (g = amatches; g; g = g->next) {
 	char **pp = g->ylist;
 	int nl = 0, l;
@@ -8031,6 +8024,16 @@
 			nlines += 1 + ((1 + niceztrlen(m->str)) / columns);
 	}
     }
+    if (!nlines) {
+	showinglist = listshown = 0;
+	return 1;
+    }
+    /* Set the cursor below the prompt. */
+    trashzle();
+    showinglist = listshown = 0;
+
+    clearflag = (isset(USEZLE) && !termflags &&
+		 complastprompt && *complastprompt);
 
     /* Maybe we have to ask if the user wants to see the list. */
     if ((!minfo.cur || !minfo.asked) &&

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

file completion bug

[Peter Stephenson]

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.

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