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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Oct 20, 2022 at 19:28:05 +0300, Eli Zaretskii wrote:
> > Date: Thu, 20 Oct 2022 15:28:48 +0000
> > Cc: akrl@sdf.org, 58634@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

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

> Or when triggered by specific API calls I mentioned above.

> > but that means solely keyboard and mouse input, doesn't it?

> Also window-system events.

> > It doesn't mean file system input, does it?

> No, not if you mean "normal" file I/O (as opposed to, say, inotify).

OK, thanks.

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

> That's exactly what needs to be explained: what triggers redisplay in
> the GUI session and why doesn't it happen in the -nw session?

I've found out quite a lot since yesterday.  What's happening is this:
(i) desktop loads an info file from .emacs.desktop.
(ii) desktop calls the Info-mode handler, Info-restore-desktop-buffer in
  info.el.
(iii) Eventually, the stack of calls reaches Info-toc-build.  This
  function calls (message "").
(iv) (message "") clears the echo area AND RESIZES IT IF NEEDED.
(v) The resizing of the echo area causes the main window to be
  redisplayed.
(vi) Since the window-buffer of the main window hasn't yet been set to
  the new info buffer, redisplay displays the buffer from the PREVIOUS
  call to desktop-create-buffer.

So it's that (message "") which is triggering redisplay.

The call to (message "") in Info-toc-build must be a bug.  This function
has no business doing anything in the echo area, its purpose being to
generate a table of contents.  I think it's likely that this is what
erases desktop's message about having visited .emacs.desktop.

I think that my GUI session was displaying more buffers because its frame
is narrower, hence more messages in the echo area needed two lines.  Thus
more info buffers caused the resizing of the echo area.

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

> That just takes getting used to.

I've got used to it.  I still say it's a bad thing.  Somebody whose
..emacs.desktop contains no info files and doesn't do things like calling
flyspell will see Emacs hang for a long time.

> And anyway, let's postpone this part of the discussion until we
> understand what happens in the -nw session that makes it behave
> differently.  because we are talking about a phenomenon we don't
> understand well enough.

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

> I don't see why it should irritate: you cannot do anything with Emacs
> during that time anyway.

It irritates, because it looks like Emacs has crashed.  There is no
feedback.  If Emacs really has crashed whilst loading the desktop, how
long should the user wait before getting angry?  Again, I propose
outputting progress dots, possibly as an enabled by default option.

And I propose removing the (message "") from Info-toc-build, and amending
what this was designed to do in the proper place, wherever that might be.

-- 
Alan Mackenzie (Nuremberg, Germany).