Subject: bug#61667: 29.0.60; Failure to redisplay

From: Dmitry Gutov <[email-masked]>
Date: Sun, 26 Feb 2023 15:21:40 +0200

On 26/02/2023 14:31, Eli Zaretskii wrote:
>> Date: Sun, 26 Feb 2023 14:23:49 +0200
>> Cc:[email-masked],[email-masked],[email-masked]
>> From: Dmitry Gutov<[email-masked]>
>>
>> On 26/02/2023 14:13, Eli Zaretskii wrote:
>>> Thanks, but I still need to insist on more clarity, if possible.
>>>
>>> You say "disappears", in quotes, presumably to say that it's still
>>> present but hard to notice?  And before that, you say the delay is
>>> always physically present?
>> The delay is distance in time. It can't really be zero -- that's just
>> physics: the OS has to process the keypress, Emacs has to read the file,
>> run the major mode function, etc.
>>
>> The problem is when that delay becomes high enough to notice with a
>> naked eye.
> And that happens even if the frame title is not changed?

No.

Here are all the ways we have found that make the problem go away:

--eval "(modify-frame-parameters nil '((inhibit-double-buffering . t)))"

--eval "(setq frame-title-format \"foo bar foo\")"

--eval "(modify-frame-parameters nil '((undecorated . t)))"

When any of these arguments is passed to Emacs, the problem does not 
reproduce anymore.

> IOW, is time interval between pressing RET at the end of the command
> which starts Emacs and the time the text area of the window shows the
> file's text -- is this time interval the same whether the frames title
> changes or not?

The command doesn't trigger Emacs to visit a file, though.

So I mean the delay between me either

- Pressing 'a' in one scenario (the 'emacs -Q ...' one)
- Or pressing 'C-x b xas RET' (using Ido completion with my config)

and the buffer's text being displayed.