From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-9953-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 3430 invoked from network); 1 Mar 2000 14:01:56 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 1 Mar 2000 14:01:56 -0000
Received: (qmail 11586 invoked by alias); 1 Mar 2000 14:01:47 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 9953
Received: (qmail 11556 invoked from network); 1 Mar 2000 14:01:43 -0000
Date: Wed, 1 Mar 2000 15:01:40 +0100 (MET)
Message-Id: <200003011401.PAA27932@beta.informatik.hu-berlin.de>
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
In-reply-to: Tanaka Akira's message of 01 Mar 2000 22:11:43 +0900
Subject: Re: PATCH: completion tests


Tanaka Akira wrote:

> ...
> 
> The problem I wanted to mention in 9936 is that zsh doesn't delimit
> display strings properly as:

I wasn't aware of the unbalanced codes for display strings, but I
understood you all right. My suggestion was to force display strings
to be delimited by using a list-colors pattern and to make that
pattern match only display strings by testing if the string contains a 
space -- which display strings normally do and for other normal match
strings we could probably avoid it in completion tests.

However...

> Z(2):akr@is27e1u11% Src/zsh -f Test/comptest -D -z Src/zsh $'flex -\t' 
> line: {flex -}{}
> DESCRIPTION:{option}
> NO:{-+ -- generate C++ scanner class}
> NO:{--version}
> Z(2):akr@is27e1u11% bin2ascii /tmp/comptest.debug|head                
> f\bflex -<WIDGET><expand-or-complete>\r
> <LBUFFER>flex -</LBUFFER>\r
> <RBUFFER></RBUFFER>\r
> \x1B[H\x1B[2J\x1B[m\x1B[m\x1B[m\x1B[J<PROMPT>flex -\x1B[K\r\r
> <DESCRIPTION>option</DESCRIPTION>\x1B[K\r
> \x1B[K\r
> <LC><NO><RC>-+ -- generate C++ scanner class\x1B[K<EC>\r
> \r
> -7 -- generate 7-bit scanner\x1B[K<EC>\r
> \r
> Z(2):akr@is27e1u11% 
> 
> If `-7 -- generate 7-bit scanner' is delimited by <LC><NO><RC> and
> <EC>, we can extract the string.  But there is no <LC><NO><RC> before
> the string and `\e[K' is inserted before <EC>.

The problem was that the ec-code was output differently and for all
other codes there was the optimisation to not print them again when we 
already printed them and no other code since then.

The patch below should force the lc/no/rc codes to be printed again
after we printed ec. In terms of optimisation, this is a bit unlucky,
but since ec may contain anything, it was indeed wrong before.

I couldn't test it with comptest, though, because that doesn't seem to 
work for me, dunno where the problem is.

Bye
 Sven

diff -ru ../z.old/Src/Zle/complist.c Src/Zle/complist.c
--- ../z.old/Src/Zle/complist.c	Wed Mar  1 11:37:44 2000
+++ Src/Zle/complist.c	Wed Mar  1 14:34:43 2000
@@ -403,7 +403,7 @@
 static void
 zlrputs(Listcols c, char *cap)
 {
-    if (strcmp(last_cap, cap)) {
+    if (!*last_cap || strcmp(last_cap, cap)) {
 	VARARR(char, buf, lr_caplen + max_caplen + 1);
 
 	strcpy(buf, c->files[COL_LC]->col);
@@ -435,9 +435,10 @@
 static void
 zcoff(void)
 {
-    if (mcolors.files[COL_EC] && mcolors.files[COL_EC]->col)
+    if (mcolors.files[COL_EC] && mcolors.files[COL_EC]->col) {
 	tputs(mcolors.files[COL_EC]->col, 1, putshout);
-    else
+	*last_cap = '\0';
+    } else
 	zcputs(&mcolors, NULL, COL_NO);
 }
 

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