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

[Alan Mackenzie]

Hello, Eli.

On Thu, Oct 20, 2022 at 16:07:48 +0300, Eli Zaretskii wrote:
> > 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.

Yes.

> > > 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".

I suppose it's more an observation (from instrumentation of the desktop
loading) than an explanation.  When a buffer takes longer than usual to
be read, the previous buffer sometimes gets displayed.

> 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.

I am puzzled by what is triggering the redisplay at all.  Redisplay will
happen when "Emacs is waiting for input", but that means solely keyboard
and mouse input, doesn't it?  It doesn't mean file system input, does it?

So once Emacs starts the desktop loading with a call to `load', there
would appear to be nothing (in my setup, not yours) to trigger redisplay
until the load is complete.  But it happens in a GUI Emacs and sometimes
in a tty Emacs.  It happened for me on the linux console when I rebuilt
my Emacs 29 without native compilation; I got, IIRC, two buffers
displayed.

> > 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?

Because it looks, for an extended period of time, like Emacs has hung
completely.  This is going to irritate people, and might prompt some
users to abort Emacs.  If it can be 18 seconds blank screen for me, it
could easily be 2 minutes for somebody else with a larger desktop file or
a slower machine.

-- 
Alan Mackenzie (Nuremberg, Germany).