GNU bug report logs - #61667
29.0.60; Failure to redisplay

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org
Subject: bug#61667: 29.0.60; Failure to redisplay
Date: Tue, 21 Feb 2023 18:05:14 +0200

> Date: Tue, 21 Feb 2023 17:51:01 +0200
> Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > If you build with no optimizations (CFLAGS=-O0 ./configure...), but
> > without --enable-checking=glyphs, does the problem still happen?
> 
> Still reproduces, yes. As long as I don't hurry too much to type 'C-x b 
> file-name RET' too early, before the frame has managed to resize and 
> redisplay fully the first time.

I'm not surer I follow: why should a frame resize in this case?  You
just visit a file in an existing window of an existing frame, right?
Or is the situation more complicated?  If the latter, please tell the
details, they could be relevant.

> So if I wait for it, and then use 'C-x b' (with Ido's support for 
> recentf), then I also can trigger the problem.

Not following again: wait for what?  And what happens when you use
"C-x b"?

> Oh, here's another description of the bug: the frame's title bar changes 
> (to display the visited file name), but the buffer is blank for a little 
> while.

Which seems to mean that redisplay was called (and produced the
updated frame title), but for some reason decided that none of the
windows need redrawing.  Or (given your report about double-buffering)
didn't reflect the new content on display?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.