PATCH: completion listing (was: zsh hangup with listpacked and Problem with zle completion listing function)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Tanaka Akira wrote:

> I found zsh hangup with listpacked on 80x24 terminal as follows.
> 
> Z(2):akr@flux% zsh -f
> flux% stty size
> 24 80
> flux% echo $ZSH_VERSION 
> 3.1.9-dev-8
> flux% autoload -U compinit; compinit -D; setopt listpacked; compdef _tst tst
> flux% _tst () {
> function> compadd aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> function> }
> flux% tst <TAB>
> 
> A shorter or longer `a's doesn't cause hangup.

Oops, wrong test in some places (one place, copied multiple times).


Peter Stephenson wrote:

> I have the following function set up as an ordinary zle widget, with zle
> -N, and bound to ^D.  It's supposed to make sure that when I type ^D I
> always get a freshly calculated list, so that I can list the contents of a
> directory which appears with menu completion --- otherwise it will just
> redraw the current menu list.  (Of course, what I *really* want is
> something smarter: if a list is already displayed, assume I want it updated
> based on what's currently on the command line, but I couldn't work out how
> to do that.)

Hm. I don't exactly understand how this would differ from your
version...?

> ...
> 
> It's a hack, but it still doesn't work.  First, I only get the new list the
> second time I type ^D.  More explicitly: suppose I am in the top-level zsh
> directory with menucomplete set, and type `echo Co<TAB>'.  This will show
> `Completion/'; a further TAB would show `Config/'.  Now I type '^D'.  The
> first time, I just get the same list, only the second time do I get the
> contents I want.  I'm sure I should be able to work out what's going on,
> but it's not immediately obvious.

I can't reproduce this. I tried it with and without autolist and with
and without _oldlist in the completer list. Even if the patch below
fixes the main problem I'd like to be able to track this down.

> The real problem is when I type '^D' a third time: the shell then crashes.
> This is obviously a real bug.  Here's the backtrace.  `*minfo.cur' is
> 0xffffffff, which is obviously not a good thing to dereference.

It was trying to access an already freed match, I guess. The patch
makes minfo.cur be reset whenever the matches are freed.


Bye
 Sven

Index: Src/Zle/compcore.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compcore.c,v
retrieving revision 1.41
diff -u -r1.41 compcore.c
--- Src/Zle/compcore.c	2000/10/11 12:19:25	1.41
+++ Src/Zle/compcore.c	2001/01/08 15:20:28
@@ -2932,4 +2932,5 @@
 
 	g = n;
     }
+    minfo.cur = NULL;
 }
Index: Src/Zle/compresult.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compresult.c,v
retrieving revision 1.27
diff -u -r1.27 compresult.c
--- Src/Zle/compresult.c	2000/10/25 08:18:45	1.27
+++ Src/Zle/compresult.c	2001/01/08 15:20:29
@@ -1495,7 +1495,7 @@
 				ws[tcol++] = maxlen;
 				width += maxlen;
 			    }
-			    if (!count && width < columns &&
+			    if (!count && width <= columns &&
 				(tcols <= 0 || beg == end))
 				break;
 
@@ -1536,7 +1536,7 @@
 				ws[tcols++] = maxlen;
 				width += maxlen;
 			    }
-			    if (nth == yl && width < columns &&
+			    if (nth == yl && width <= columns &&
 				(beg == end || tlines >= g->lins))
 				break;
 
@@ -1593,7 +1593,7 @@
 			    ws[tcol++] = maxlen;
 			    width += maxlen;
 			}
-			if (!count && width < columns &&
+			if (!count && width <= columns &&
 			    (tcols <= 0 || beg == end))
 			    break;
 
@@ -1642,7 +1642,7 @@
 			    ws[tcols++] = maxlen;
 			    width += maxlen;
 			}
-			if (nth == g->dcount && width < columns &&
+			if (nth == g->dcount && width <= columns &&
 			    (beg == end || tlines >= g->lins))
 			    break;
 

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx