bug#61667: 29.0.60; Failure to redisplay

[Dmitry Gutov]

On 26/02/2023 14:31, Eli Zaretskii wrote:
> > Date: Sun, 26 Feb 2023 14:23:49 +0200
> > Cc:luangruo@yahoo.com,61667@debbugs.gnu.org,gregory@heytings.org
> > From: Dmitry Gutov<dgutov@yandex.ru>
> >
> > 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.