bug#58634: Long delay with blank screen whilst loading desktop at emacs startup

[Eli Zaretskii]

> Date: Thu, 20 Oct 2022 10:55:40 +0000
> Cc: akrl@sdf.org, 58634@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > Because with Emacs 28 I use desktop.el all the time, and I do see the
> > frame displaying some files and messages in the echo-area.
> 
> Remember, the blank screen only happens for me in emacs -nw and on the
> linux console, not in GUI X.

This has yet to be explained.  See below.

> > If the same happens for you with Emacs 28, I guess it's somehow
> > related to your init files and/or what exactly is in your session.
> > For example, my sessions always include some buffers under Text mode
> > or its descendants, and those turn on Flyspell mode in my
> > configuration; starting Flyspell mode launches the speller as a
> > sub-process, and that usually triggers some form of redisplay.  In
> > addition, I have garbage-collection-messages turned on, so GC-related
> > messages are shown in the echo-area, which also is a kind of
> > redisplay.  Restoring file buffers sometimes produces prompts, e.g. if
> > the file is too large or there are local variables there that require
> > confirmation -- and those prompts trigger redisplay as well.
> 
> > If you have none of that in your configuration, perhaps desktop.el can
> > indeed produce a completely blank frame.  Although it sounds strange
> > to me, since I never saw anything like that.  But it could be because
> > I'm used to starting Emacs with my configuration.
> 
> All this supports my hypothesis (above).  Anything which is "slow"
> causes a redisplay during desktop loading.  For each buffer loaded,
> there is a switch-to-buffer call, so anything causing a redisplay will
> display that buffer.

I don't follow this reasoning.  Emacs is a single-threaded program, so
redisplay or lack thereof cannot be explained by something being
"slow".  Because once redisplay is triggered, it runs to completion,
whether it's "slow" or not.  So if redisplay doesn't happen in one
case it means it wasn't triggered.  Things that trigger redisplay are
calls to 'message', to 'sit-for', explicit call to 'redisplay', and
some others.

> If you agree with me that this needs fixing (I think you do), I have two
> ideas on how to fix it:

I don't yet see what is the problem we are supposed to fix here.  Even
if, after we dig deeper into this and understand why the frame stays
blank in the console case, why is that a problem that needs fixing?