* cosmetic completion problem
@ 2005-10-06 20:58 Clint Adams
2005-10-08 7:32 ` DervishD
0 siblings, 1 reply; 6+ messages in thread
From: Clint Adams @ 2005-10-06 20:58 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: cosmetic completion problem
2005-10-06 20:58 cosmetic completion problem Clint Adams
@ 2005-10-08 7:32 ` DervishD
2005-10-08 21:40 ` Clint Adams
0 siblings, 1 reply; 6+ messages in thread
From: DervishD @ 2005-10-08 7:32 UTC (permalink / raw)
To: zsh-workers
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...
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: cosmetic completion problem
2005-10-08 7:32 ` DervishD
@ 2005-10-08 21:40 ` Clint Adams
2005-10-09 2:54 ` Bart Schaefer
0 siblings, 1 reply; 6+ messages in thread
From: Clint Adams @ 2005-10-08 21:40 UTC (permalink / raw)
To: zsh-workers
> 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;
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: cosmetic completion problem
2005-10-08 21:40 ` Clint Adams
@ 2005-10-09 2:54 ` Bart Schaefer
2005-10-10 9:37 ` Peter Stephenson
0 siblings, 1 reply; 6+ messages in thread
From: Bart Schaefer @ 2005-10-09 2:54 UTC (permalink / raw)
To: Clint Adams, zsh-workers
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).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: cosmetic completion problem
2005-10-09 2:54 ` Bart Schaefer
@ 2005-10-10 9:37 ` Peter Stephenson
2005-10-10 14:06 ` Bart Schaefer
0 siblings, 1 reply; 6+ messages in thread
From: Peter Stephenson @ 2005-10-10 9:37 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: cosmetic completion problem
2005-10-10 9:37 ` Peter Stephenson
@ 2005-10-10 14:06 ` Bart Schaefer
0 siblings, 0 replies; 6+ messages in thread
From: Bart Schaefer @ 2005-10-10 14:06 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-10-10 14:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-06 20:58 cosmetic completion problem Clint Adams
2005-10-08 7:32 ` DervishD
2005-10-08 21:40 ` Clint Adams
2005-10-09 2:54 ` Bart Schaefer
2005-10-10 9:37 ` Peter Stephenson
2005-10-10 14:06 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).