Re: 3.1.6 bug in NextStep/OpenStep 4.2

Re: 3.1.6 bug in NextStep/OpenStep 4.2

[Sven Wischnowsky]

Brian Boonstra wrote:

> ...
>
> 	However, completion is not quite right.  In particular, if I run  
> either the usual binary, I get completion with extra "2" characters, like  
> this:
> 
> wo1203 % ls ../co                              /tmp/zsh/zsh-3.1.6/Src
> Completion/   2  2config.guess* 2  2config.log    2  2configure*    2
> Config/       2  2config.h      2  2config.status*2  2configure.in  2
> config.cache  2  2config.h.in   2  2config.sub*   2  2              2

I don't know about the other things, but I guess this is the same
problem mentioned by Brien Harvell (in 7443), only that he got `$<2>'
instead of the `2'.

To repeat: I think this is caused by the complist code. It prints the
termcap string for `%s' (standout off) at those places. What irritated 
me is that `print -P "%s"' didn't give him those `$<2>' strings.

I then suggested the patch in 7455 (which is appended below for your
convenience), but got no reply from him after that, so I don't know if 
it fixes the problem (I guess not).

Otherwise, I can only suspect a broken term{cap,info} entry, but then
you would have noticed that before, I think.

So it boils down to: I don't really know where the problem is but I'd
really like to fix it. Anyone have any ideas about this?

Bye
 Sven

diff -u os/Zle/complist.c Src/Zle/complist.c
--- os/Zle/complist.c	Thu Aug 19 16:00:04 1999
+++ Src/Zle/complist.c	Fri Aug 20 10:14:29 1999
@@ -194,13 +194,17 @@
     }
 }
 
+/* Combined length of LC and RC, maximum length of capability strings. */
+
+static int lr_caplen, max_caplen;
+
 /* This initializes the given terminal color structure. */
 
 static void
 getcols(Listcols c)
 {
     char *s;
-    int i;
+    int i, l;
 
     if (!(s = getsparam("ZLS_COLORS")) &&
 	!(s = getsparam("ZLS_COLOURS"))) {
@@ -222,9 +226,15 @@
 	s = getcoldef(c, s);
 
     /* Use default values for those that aren't set explicitly. */
-    for (i = 0; i < NUM_COLS; i++)
+    max_caplen = lr_caplen = 0;
+    for (i = 0; i < NUM_COLS; i++) {
 	if (!c->cols[i])
 	    c->cols[i] = defcols[i];
+	if ((l = (c->cols[i] ? strlen(c->cols[i]) : 0)) > max_caplen)
+	    max_caplen = l;
+    }
+    lr_caplen = strlen(c->cols[COL_LC]) + strlen(c->cols[COL_RC]);
+
     /* Default for missing files. */
     if (!c->cols[COL_MI])
 	c->cols[COL_MI] = c->cols[COL_FI];
@@ -235,14 +245,24 @@
 static int last_col = COL_NO;
 
 static void
+zlrputs(Listcols c, char *cap)
+{
+    VARARR(char, buf, lr_caplen + max_caplen + 1);
+
+    strcpy(buf, c->cols[COL_LC]);
+    strcat(buf, cap);
+    strcat(buf, c->cols[COL_RC]);
+
+    tputs(buf, 1, putshout);
+}
+
+static void
 zcputs(Listcols c, int colour)
 {
     if (colour != last_col
 	&& (last_col < COL_NO
 	    || strcmp(c->cols[last_col], c->cols[colour]))) {
-	fputs(c->cols[COL_LC], shout);
-	fputs(c->cols[colour], shout);
-	fputs(c->cols[COL_RC], shout);
+	zlrputs(c, c->cols[colour]);
 	last_col = colour;
     }
     return;
@@ -260,11 +280,9 @@
     for (e = c->exts; e; e = e->next)
 	if (strsfx(e->ext, n)) {	/* XXX: unoptimised if used */
 	    if (last_col < COL_NO
-		|| strcmp(c->cols[last_col], e->col)) {
-		fputs(c->cols[COL_LC], shout);
-		fputs(e->col, shout);
-		fputs(c->cols[COL_RC], shout);
-	    }
+		|| strcmp(c->cols[last_col], e->col))
+		zlrputs(c, e->col);
+
 	    last_col = COL_NO - 1;
 	    return;
 	}
@@ -565,7 +583,7 @@
 			while (a--)
 			    putc(' ', shout);
 			if (col.cols[COL_EC])
-			    fputs(col.cols[COL_EC], shout);
+			    tputs(col.cols[COL_EC], 1, putshout);
 			else
 			    zcputs(&col, COL_NO);
 			break;
@@ -614,14 +632,14 @@
 		    while (a--)
 			putc(' ', shout);
 		    if (col.cols[COL_EC])
-			fputs(col.cols[COL_EC], shout);
+			tputs(col.cols[COL_EC], 1, putshout);
 		    else
 			zcputs(&col, COL_NO);
 		    if (i) {
 			zcputs(&col, COL_NO);
 			fputs("  ", shout);
 			if (col.cols[COL_EC])
-			    fputs(col.cols[COL_EC], shout);
+			    tputs(col.cols[COL_EC], 1, putshout);
 			else
 			    zcputs(&col, COL_NO);
 		    }
@@ -636,7 +654,7 @@
 		    while (a--)
 			putc(' ', shout);
 		    if (col.cols[COL_EC])
-			fputs(col.cols[COL_EC], shout);
+			tputs(col.cols[COL_EC], 1, putshout);
 		    else
 			zcputs(&col, COL_NO);
 		}

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

Re: 3.1.6 bug in NextStep/OpenStep 4.2

[Brian Boonstra]

Hi Sven (and all)

	I applied the patch (in 7513 and 7455) and it fixed the problem  
perfectly!  Similarly to what Brian H. saw, `print -P "%s"' was not giving me  
any extraneous characters.

	For the benefit of those joining late, in order to get zsh 3.1.6 to  
compile on OpenStep, you also need the patch from 2372.

	BTW, Sven, this is especially welcome on OpenStep/NextStep, because  
the Terminal application supplied by them is so darn good that few people  
ever use anything else.  And it does only vt100.


		Thanks,


			Brian



Sven Wischnowsky wrote:
> Brian Boonstra wrote:
> > However, completion is not quite right.  In particular, if I run
> > either the usual binary, I get completion with extra "2" characters, like
> > this:
> I don't know about the other things, but I guess this is the same
> problem mentioned by Brien Harvell (in 7443), only that he got `$<2>'
> instead of the `2'.
>
> To repeat: I think this is caused by the complist code. It prints the
> termcap string for `%s' (standout off) at those places. What irritated
> me is that `print -P "%s"' didn't give him those `$<2>' strings.
>
> I then suggested the patch in 7455 (which is appended below for your
> convenience), but got no reply from him after that, so I don't know if
> it fixes the problem (I guess not).

Re: NEW BUG: 3.1.6 bug in NextStep/OpenStep 4.2

[Brian Boonstra]

Hi Folks

	Well, I have a compilation that runs, and completion works well.   
But now I notice that the terminal hangs after I perform any kind of command  
except shell builtins.  For example, "ls", "df", and "finger" all hang after  
their output, whereas "echo" and "alias" do not hang.

	Note that this has nothing to do with the patch Sven supplied to fix  
complist.c.  I have applied one other set of patches, though, namely the  
ones found here:

		http://www.zsh.org/mla/workers//1999/msg02372.html


	I doubt they are at fault, since they only patch the necessary (for  
me) third argument onto fcntl in utils.c and init.c.


	I tried compiling a debug version, but that version always gives a  
Bus Error on the first keystroke, so I'm afraid I can't be more specific.   
Anybody have ideas?



		Regards,


				Brian



Brian Boonstra wrote:
> I applied the patch (in 7513 and 7455) and it fixed the problem
> perfectly! Similarly to what Brian H. saw, `print -P "%s"' was not giving
> me any extraneous characters.
>
> For the benefit of those joining late, in order to get zsh 3.1.6 to
> compile on OpenStep, you also need the patch from 2372.
>
> ...
>
> Sven Wischnowsky wrote:
> > Brian Boonstra wrote:
> > I don't know about the other things, but I guess this is the same
> > problem mentioned by Brien Harvell (in 7443), only that he got `$<2>'
> > instead of the `2'.
> >
> > To repeat: I think this is caused by the complist code. It prints the
> > termcap string for `%s' (standout off) at those places. What irritated
> > me is that `print -P "%s"' didn't give him those `$<2>' strings.
> >
> > I then suggested the patch in 7455 (which is appended below for your
> > convenience), but got no reply from him after that, so I don't know if
> > it fixes the problem (I guess not).

Re: NEW BUG: 3.1.6 bug in NextStep/OpenStep 4.2

[Brian Boonstra]

Hi

> Note that this has nothing to do with the patch Sven supplied to fix
> complist.c


	I forgot to mention that the reason I know this is that I purposely  
compiled a version without Sven's patch.  The completion bug was back (as  
expected) and the hanging bug was there as well.




			- Brian