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

Previous Next

Full log

Message #59 received at 61667 <at> debbugs.gnu.org (full text, mbox):

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

On 21/02/2023 20:31, Eli Zaretskii wrote:
>> Date: Tue, 21 Feb 2023 19:25:28 +0200
>> Cc: luangruo <at> yahoo.com, 61667 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>> 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.
>>
>> Given how slow the unoptimized build is, I can usually start (and
>> finish) typing the command before Emacs has fully finished processing
>> the init script, including the default face customizations (which result
>> in frame resizing).
>>
>>>> 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"?
>>
>> 'C-x b' followed by the file name from history, followed by RET ->
>> visiting the previously visited file. From recentf.
>>
>> This behavior is driven by the option ido-virtual-buffers. Unlikely
>> affects something.
>>
>> But it allows me to shorten the scenario of visiting a file for the
>> first time after launching Emacs, so that I can trigger the bug faster
>> (over several tries).
> 
> So you:
> 
>    . start Emacs
>    . wait for the initial frame to be redrawn after the init files are
>      processed
>    . visit a file by typing "C-x b" and selecting a file from a list
> 
> And then you see an empty window with the frame's title showing the
> file you selected.  Is that correct?

Not exactly empty, just not updated. I guess I was saying it's blank 
because the scratch is usually displayed as blank. But I wasn't able to 
repro this with non-empty scratch. Not in the latest experiments, at least.

> If so, what do you see on the
> mode line as the buffer name?

Whatever it was showing before I hit RET. Its contents for *scratch*, I 
guess.

>> Overall, though, the unoptimized build makes it harder to reproduce:
>> I've only managed that 3 times, so far.
> 
> Which likely means this is some kind of timing issue.  Which perhaps
> also explains why trace-redisplay stops it from happening: it slows
> down redisplay because it needs to output the traces.  So we are
> looking at some X or GTK event that comes in and somehow interrupts or
> prevents redisplay from doing its job, after it evidently started
> (because the frame title is updated at the beginning of a redisplay
> cycle)?  Or maybe it's something that prevents us from swapping the
> double-buffering buffers so that the redrawn stuff is actually shown
> on the glass?

I understand you are musing here.

>> But the echo area is not getting redrawn either: the selection of
>> buffers to switch to is still visible as it was when I pressed RET. Just
>> the title bar changes. The echo area is updated together with the main
>> window showing the buffer.
> 
> The echo area is shown in a window, so that seems to be part of not
> updating the windows on display.

Yep. Or to be more precise, the whole frame contents are not updated. 
Just the title. At first.

Previous Next

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