cosmetic completion problem

cosmetic completion problem

[Clint Adams]

While trying to reproduce a segfault, I noticed this.

% touch "AAAA BBBB CCCC DDDD EEEE FFFF GGGG HHHH IIII JJJJ KKKK LLLL MMMM NNNN OOOO PPPP "{1..50}
% blah <hit tab a few times>

A line is skipped when redrawing, and this does not get corrected until
the matches start scrolling.

Re: cosmetic completion problem

[DervishD]

    Hi Clint :)

 * Clint Adams <clint@zsh.org> dixit:
> While trying to reproduce a segfault, I noticed this.
> 
> % touch "AAAA BBBB CCCC DDDD EEEE FFFF GGGG HHHH IIII JJJJ KKKK LLLL MMMM NNNN OOOO PPPP "{1..50}
> % blah <hit tab a few times>
> 
> A line is skipped when redrawing, and this does not get corrected
> until the matches start scrolling.

    Curious. If I try that (but with a longer name length, since I
have a 100 col-wide terminal) I have exactly the same instead of the
usual infinite loop or crash. The screen just messes up.

    This looks like confirming that the bug (well, the infinite loop
and the crash) only happens when any element in the list has exactly
$COLUMNS characters, including not only the "real" characters but
any backslash that metafies any other char. Longer filenames doesn't
seem to have this effect, although I should better test...

    BTW, Clint, which version of zsh are you using?

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: cosmetic completion problem

[Clint Adams]

>     BTW, Clint, which version of zsh are you using?

CVS HEAD.

This seems to fix part of the problem, but not all of it.  I don't know
what it breaks.

--- orig/Src/Zle/complist.c
+++ mod/Src/Zle/complist.c
@@ -653,7 +653,7 @@
 	     * There might be problems with characters of printing width
 	     * greater than one here.
 	     */
-	    if (col >= columns) {
+	    if (col > columns) {
 		ml++;
 		if (mscroll && !--mrestlines && (ask = asklistscroll(ml))) {
 		    mlprinted = ml - oml;

Re: cosmetic completion problem

[Bart Schaefer]

On Oct 8,  5:40pm, Clint Adams wrote:
} Subject: Re: cosmetic completion problem
}
} This seems to fix part of the problem, but not all of it.  I don't know
} what it breaks.

This doesn't help at all for me.  I still get a reproducible crash.  (I
applied the equivalent patch to the non-unicode section of the code.)

Inside that same (col >= columns) block is an fputs() call that's intended
to make sure that the line really has wrapped when col == columns.  I'm
not sure, looking at it, why that's only necessary when (colors).

Re: cosmetic completion problem

[Peter Stephenson]

Bart Schaefer wrote:
> Inside that same (col >= columns) block is an fputs() call that's intended
> to make sure that the line really has wrapped when col == columns.  I'm
> not sure, looking at it, why that's only necessary when (colors).

This doesn't really help, but until I added the ZLE_UNICODE_SUPPORT
there were two separate functions, one which handled colours and one
which didn't.  I rationalised them into one with a flag for the few
local differences.

What might be more interesting is that I changed

	    if (++col == columns) {

into

	    if (col >= columns) {

which might well have introduced a subtle bug.  The reason I introduced it
was we may have characters spanning multiple columns, but perhaps those
need something more sophisticated.  (The increment now happens in one
of the immediately preceeding code branches.)

pws



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

Re: cosmetic completion problem

[Bart Schaefer]

On Oct 10, 10:37am, Peter Stephenson wrote:
}
} What might be more interesting is that I changed
} 
} 	    if (++col == columns) {
} into
} 	    if (col >= columns) {
} 
} which might well have introduced a subtle bug.

No, that's another red herring.  The non-unicode branch still has the
original ++col and I get the crash with --disable-multibyte.  I think
the real bug happens somewhere outside this function, before execution
even gets this far.