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

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

[Alan Mackenzie]

Hello, Emacs.

In my current desktop file, I have 166 buffers.  I'm using an up to date
Emacs 29.

On loading this desktop into emacs -nw on X Windows, or into a linux
console, it takes a long time to load, around 28 seconds.  Of that time,
my terminal window/screen is entirely blank for around 18 seconds, with
not even a mode line being displayed.

Doing the same in a GUI run on X also takes around 28 seconds to load,
but during that time, random buffers are displayed on the screen,
complete with mode line.

I think the native compiler is running in the background during this 28
seconds, and thus contributes to the relatively long start up time.

This ~18 seconds of blank screen is likely to be disconcerting to some
users, and thus surely should be reckoned as a bug.

My current configuration of Emacs 29 has --with-native-compilation set,
otherwise, nothing relevant

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Wed, 19 Oct 2022 13:28:42 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> In my current desktop file, I have 166 buffers.  I'm using an up to date
> Emacs 29.
> 
> On loading this desktop into emacs -nw on X Windows, or into a linux
> console, it takes a long time to load, around 28 seconds.  Of that time,
> my terminal window/screen is entirely blank for around 18 seconds, with
> not even a mode line being displayed.

And nothing in the echo-area, either?

> Doing the same in a GUI run on X also takes around 28 seconds to load,
> but during that time, random buffers are displayed on the screen,
> complete with mode line.
> 
> I think the native compiler is running in the background during this 28
> seconds, and thus contributes to the relatively long start up time.

To test this hypothesis, leave Emacs alone running until
list-processes shows an empty list, then restart Emacs.  This time,
you should not see the delay due to native compilation, so if there
still is a delay, it is unlikely to be due to native compilation.

In any case, you should be able to see whether it's native compilation
by watching the emacs --batch processes that run on your system during
that time.

In general, even if the native compilation is running at startup, it
should not delay the startup (barring some bug), because Emacs loads
the *.elc files when *.eln are unavailable, without waiting for the
compilation to complete.

> This ~18 seconds of blank screen is likely to be disconcerting to some
> users, and thus surely should be reckoned as a bug.

So please help us understand what causes this, so we could fix it.

Thanks.

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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 19 Oct 2022 13:28:42 +0000
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> In my current desktop file, I have 166 buffers.  I'm using an up to date
>> Emacs 29.
>> 
>> On loading this desktop into emacs -nw on X Windows, or into a linux
>> console, it takes a long time to load, around 28 seconds.  Of that time,
>> my terminal window/screen is entirely blank for around 18 seconds, with
>> not even a mode line being displayed.
>
> And nothing in the echo-area, either?
>
>> Doing the same in a GUI run on X also takes around 28 seconds to load,
>> but during that time, random buffers are displayed on the screen,
>> complete with mode line.
>> 
>> I think the native compiler is running in the background during this 28
>> seconds, and thus contributes to the relatively long start up time.
>
> To test this hypothesis, leave Emacs alone running until
> list-processes shows an empty list, then restart Emacs.  This time,
> you should not see the delay due to native compilation, so if there
> still is a delay, it is unlikely to be due to native compilation.
>
> In any case, you should be able to see whether it's native compilation
> by watching the emacs --batch processes that run on your system during
> that time.

Yes totally agree, listing processes is the quickest way to confirm this
hypothesis.

Alan please let us know.

  Andrea

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

[Alan Mackenzie]

Hello, Eli and Andrea.

On Wed, Oct 19, 2022 at 19:11:38 +0000, Andrea Corallo wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> Date: Wed, 19 Oct 2022 13:28:42 +0000
> >> From: Alan Mackenzie <acm@muc.de>

> >> In my current desktop file, I have 166 buffers.  I'm using an up to date
> >> Emacs 29.

> >> On loading this desktop into emacs -nw on X Windows, or into a linux
> >> console, it takes a long time to load, around 28 seconds.  Of that time,
> >> my terminal window/screen is entirely blank for around 18 seconds, with
> >> not even a mode line being displayed.

> > And nothing in the echo-area, either?

Nothing in the echo-area, no.

> >> Doing the same in a GUI run on X also takes around 28 seconds to load,
> >> but during that time, random buffers are displayed on the screen,
> >> complete with mode line.

> >> I think the native compiler is running in the background during this 28
> >> seconds, and thus contributes to the relatively long start up time.

> > To test this hypothesis, leave Emacs alone running until
> > list-processes shows an empty list, then restart Emacs.  This time,
> > you should not see the delay due to native compilation, so if there
> > still is a delay, it is unlikely to be due to native compilation.

I did this, and there was still a delay.  So I'm pretty sure it's nothing
to do with native compilation, now.

> > In any case, you should be able to see whether it's native compilation
> > by watching the emacs --batch processes that run on your system during
> > that time.

> Yes totally agree, listing processes is the quickest way to confirm this
> hypothesis.

> Alan please let us know.

It's nothing to do with native compilation.  Apologies.

What I did do was insert debugging code which prints an extra . for each
loaded file.  More precisely:

diff --git a/lisp/desktop.el b/lisp/desktop.el
index ef73bc596d..554e82ab40 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -1599,6 +1607,10 @@ desktop-create-buffer
            (setq desktop-buffer-ok-count (1+ desktop-buffer-ok-count))
          (setq desktop-buffer-fail-count (1+ desktop-buffer-fail-count))
          (setq result nil))
+        (let ((buffer-total-count (+ desktop-buffer-ok-count
+                                     desktop-buffer-fail-count)))
+          (message (concat "Restoring desktop..."
+                           (make-string buffer-total-count ?.))))
        ;; Restore buffer list order with new buffer at end. Don't change
        ;; the order for old desktop files (old desktop module behavior).
        (unless (< desktop-file-version 206)

On my linux console, this displays a few buffers (out of ~166) in
addition to the dots in the echo area.

I have a theory.  The function desktop-restore-file-buffer visits a file
with find-file-noselect, then calls switch-to-buffer on it.  (This is the
interactive command on C-x b.)  In earlier times, there would be a delay
in visiting the next file, and in this delay redisplay would happen.  The
user would thus see a sequence of short displays of his files being
loaded.  Nowadays, the time to visit a file is so short that redisplay
never registers a delay, and so doesn't redisplay.  But with something
slowing the processing down a little (outputting "Restoring
desktop......", for example), the OS's file system goes to sleep, and
takes long enough to wake up for redisplay to trigger.  Or something like
that.

What do you think?

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Wed, 19 Oct 2022 19:58:36 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 58634@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I have a theory.  The function desktop-restore-file-buffer visits a file
> with find-file-noselect, then calls switch-to-buffer on it.  (This is the
> interactive command on C-x b.)  In earlier times, there would be a delay
> in visiting the next file, and in this delay redisplay would happen.  The
> user would thus see a sequence of short displays of his files being
> loaded.  Nowadays, the time to visit a file is so short that redisplay
> never registers a delay, and so doesn't redisplay.  But with something
> slowing the processing down a little (outputting "Restoring
> desktop......", for example), the OS's file system goes to sleep, and
> takes long enough to wake up for redisplay to trigger.  Or something like
> that.
> 
> What do you think?

Does this happen with Emacs 28 as well in your configuration?  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.  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.

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

[Alan Mackenzie]

Hello, Eli.

On Thu, Oct 20, 2022 at 08:20:48 +0300, Eli Zaretskii wrote:
> > Date: Wed, 19 Oct 2022 19:58:36 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, 58634@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > I have a theory.  The function desktop-restore-file-buffer visits a file
> > with find-file-noselect, then calls switch-to-buffer on it.  (This is the
> > interactive command on C-x b.)  In earlier times, there would be a delay
> > in visiting the next file, and in this delay redisplay would happen.  The
> > user would thus see a sequence of short displays of his files being
> > loaded.  Nowadays, the time to visit a file is so short that redisplay
> > never registers a delay, and so doesn't redisplay.  But with something
> > slowing the processing down a little (outputting "Restoring
> > desktop......", for example), the OS's file system goes to sleep, and
> > takes long enough to wake up for redisplay to trigger.  Or something like
> > that.

> > What do you think?

> Does this happen with Emacs 28 as well in your configuration?

It does, yes.  More precisely, it did after I commented out some
variables in several .dir-locals that were causing "unsafe variable"
warning messages.

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

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

If you agree with me that this needs fixing (I think you do), I have two
ideas on how to fix it:
(i) (Rough and ready): Output a "progress report" in the form of a dot
  for each buffer, showing "Restoring desktop.......", exactly as in the
  patch I included yesterday.  The user might not see any buffers here,
  but will at least be reassured his Emacs hasn't hung.
(ii) (More complicated): Count the number of buffers since the last
  redisplay.  When this reaches, say, 10, cause the next buffer to be
  redisplayed by something like (sit-for 0.1), or even (redisplay) in
  desktop-restore-file-buffer.  The counter would be reset by a function
  on the hook pre-redisplay-functions.

What do you think?

-- 
Alan Mackenzie (Nuremberg, Germany).

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?

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

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

[Eli Zaretskii]

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

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

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

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.

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

[Alan Mackenzie]

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

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

[Eli Zaretskii]

> Date: Fri, 21 Oct 2022 08:59:58 +0000
> Cc: 58634@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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.

I don't see any need for adding this.  Your case seems to be a rare
one, and doesn't justify such complications.

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

I'm guessing that (message "") was there because originally that
function was showing progress messages as part of its processing:

   (or main-file (message "Searching subfile %s..." (car subfiles)))

However, this has been commented out 14 years ago, so perhaps nowadays
it isn't necessary.  Adding Juri to the CC in case he has some
comments.

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

[Alan Mackenzie]

Hello, Eli.

On Fri, Oct 21, 2022 at 14:28:09 +0300, Eli Zaretskii wrote:
> > Date: Fri, 21 Oct 2022 08:59:58 +0000
> > Cc: 58634@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

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

> I don't see any need for adding this.  Your case seems to be a rare
> one, and doesn't justify such complications.

What is rare about my case?  Assuming the (message "") gets removed from
info.el, there are just 3 things needed for the long delay to happen:
(i) Having a large .emacs.desktop;
(ii) Not encountering any error message during its loading.
(iii) Not getting any messages from flyspell and friends or the OS
during loading.

This will be a common case amongst users.

In particular, the problem is NOT confined to the tty.  It will occur on
GUI sessions, too.  When I tried it out this morning under X, the only
thing which triggered a redisplay was a version conflict error between
CC Mode and js-mode (and some status messages from shell-script-mode
very late in the loading).

My current idea is to count the buffers in desktop-save, and to output a
message:

    Restoring buffers: 127/166

as we restore the buffers.  We already count the buffers as we load
them.

This is NOT complicated.

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

> I'm guessing that (message "") was there because originally that
> function was showing progress messages as part of its processing:

>    (or main-file (message "Searching subfile %s..." (car subfiles)))

I think this is the case, yes.  There's not a lot of information about
it in the git log.

> However, this has been commented out 14 years ago, so perhaps nowadays
> it isn't necessary.  Adding Juri to the CC in case he has some
> comments.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 21 Oct 2022 12:40:32 +0000
> Cc: Juri Linkov <juri@linkov.net>, 58634@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I don't see any need for adding this.  Your case seems to be a rare
> > one, and doesn't justify such complications.
> 
> What is rare about my case?

That you see a blank frame.

> My current idea is to count the buffers in desktop-save, and to output a
> message:
> 
>     Restoring buffers: 127/166
> 
> as we restore the buffers.  We already count the buffers as we load
> them.

This will slow down the session restoration, so I'd rather avoid it.

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

[Alan Mackenzie]

Hello, Eli.

On Fri, Oct 21, 2022 at 16:22:16 +0300, Eli Zaretskii wrote:
> > Date: Fri, 21 Oct 2022 12:40:32 +0000
> > Cc: Juri Linkov <juri@linkov.net>, 58634@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > I don't see any need for adding this.  Your case seems to be a rare
> > > one, and doesn't justify such complications.

> > What is rare about my case?

> That you see a blank frame.

That is true.  On a GUI frame, Emacs is unresponsive and apperantly hung.
Not quite as bad, but also not good.

> > My current idea is to count the buffers in desktop-save, and to output a
> > message:

> >     Restoring buffers: 127/166

> > as we restore the buffers.  We already count the buffers as we load
> > them.

> This will slow down the session restoration, so I'd rather avoid it.

I've implemented it, and timed it.  With the progress reporting enabled,
it takes 0.2% longer than with it disabled.  This is negligible.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 21 Oct 2022 14:15:16 +0000
> Cc: juri@linkov.net, 58634@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > >     Restoring buffers: 127/166
> 
> > > as we restore the buffers.  We already count the buffers as we load
> > > them.
> 
> > This will slow down the session restoration, so I'd rather avoid it.
> 
> I've implemented it, and timed it.  With the progress reporting enabled,
> it takes 0.2% longer than with it disabled.  This is negligible.

In your case, maybe.

I'm against adding this kind of trace.

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

[Alan Mackenzie]

Hello, Eli.

On Fri, Oct 21, 2022 at 18:23:16 +0300, Eli Zaretskii wrote:
> > Date: Fri, 21 Oct 2022 14:15:16 +0000
> > Cc: juri@linkov.net, 58634@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > >     Restoring buffers: 127/166

> > > > as we restore the buffers.  We already count the buffers as we load
> > > > them.

> > > This will slow down the session restoration, so I'd rather avoid it.

> > I've implemented it, and timed it.  With the progress reporting enabled,
> > it takes 0.2% longer than with it disabled.  This is negligible.

> In your case, maybe.

Yes.  Even if that difference was ten times as long, or even a hundred
times as long, it would still be insignificant.  If it proves to be a
hindrance, it can always be disabled by a boolean defcustom.

> I'm against adding this kind of trace.

Yes, that's clear, but you haven't suggested anything better.  Emacs
freezing for large portions of a minute, or even longer, is not a good
thing.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 21 Oct 2022 15:42:54 +0000
> Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > I'm against adding this kind of trace.
> 
> Yes, that's clear, but you haven't suggested anything better.  Emacs
> freezing for large portions of a minute, or even longer, is not a good
> thing.

I suggest to do nothing about that.

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

[Alan Mackenzie]

Hello, Eli.

On Fri, Oct 21, 2022 at 18:57:28 +0300, Eli Zaretskii wrote:
> > Date: Fri, 21 Oct 2022 15:42:54 +0000
> > Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > I'm against adding this kind of trace.

> > Yes, that's clear, but you haven't suggested anything better.  Emacs
> > freezing for large portions of a minute, or even longer, is not a good
> > thing.

> I suggest to do nothing about that.

Yes.  I don't understand that.  Emacs hangs irritatingly, and there's a
simple fix.  You're not prepared to apply it, to try it out, or even to
look at it.

What about the other remaining matter - that (message "") in info.el?
Presumably we're waiting on some response from Juri.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 21 Oct 2022 17:15:19 +0000
> Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Eli.
> 
> On Fri, Oct 21, 2022 at 18:57:28 +0300, Eli Zaretskii wrote:
> > > Date: Fri, 21 Oct 2022 15:42:54 +0000
> > > Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> > > From: Alan Mackenzie <acm@muc.de>
> 
> > > > I'm against adding this kind of trace.
> 
> > > Yes, that's clear, but you haven't suggested anything better.  Emacs
> > > freezing for large portions of a minute, or even longer, is not a good
> > > thing.
> 
> > I suggest to do nothing about that.
> 
> Yes.  I don't understand that.  Emacs hangs irritatingly, and there's a
> simple fix.  You're not prepared to apply it, to try it out, or even to
> look at it.

If you want some messages to be displayed, you should be able to
sprinkle your init file with them, right?  You can also define a
desktop-after-read-hook function to display something, if you want.
Assuming this will make the frame display something, why impose your
personal preferences on everyone?  I'm not aware of any complaints
about what happens when desktop.el restores a session (one more reason
to consider your case a rare one).

> What about the other remaining matter - that (message "") in info.el?
> Presumably we're waiting on some response from Juri.

Yes.  Assuming my guess is correct, I'm okay with removing that.

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

[Alan Mackenzie]

Hello, Eli.

On Fri, Oct 21, 2022 at 21:12:37 +0300, Eli Zaretskii wrote:
> > Date: Fri, 21 Oct 2022 17:15:19 +0000
> > Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > Hello, Eli.

> > On Fri, Oct 21, 2022 at 18:57:28 +0300, Eli Zaretskii wrote:
> > > > Date: Fri, 21 Oct 2022 15:42:54 +0000
> > > > Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> > > > From: Alan Mackenzie <acm@muc.de>

> > > > > I'm against adding this kind of trace.

> > > > Yes, that's clear, but you haven't suggested anything better.  Emacs
> > > > freezing for large portions of a minute, or even longer, is not a good
> > > > thing.

> > > I suggest to do nothing about that.

> > Yes.  I don't understand that.  Emacs hangs irritatingly, and there's a
> > simple fix.  You're not prepared to apply it, to try it out, or even to
> > look at it.

> If you want some messages to be displayed, you should be able to
> sprinkle your init file with them, right?

No.  I want reassurance that my Emacs hasn't hung completely, and giving
some indication of how long it's going to be busy is also wanted.  Random
messages from .emacs won't help, here.

> You can also define a desktop-after-read-hook function to display
> something, if you want.

I wasn't aware of this hook.  Being run just once at the end of
desktop-read, it doesn't look like it can be used to provide any
information about the progress of that desktop-read.

> Assuming this will make the frame display something, why impose your
> personal preferences on everyone?

That's not fair.  One could make the same insinuation against anybody who
added an option for users.  My "personal preferences" here are a totally
neutral, factual display which is not imposed on anybody; there is a
defcustom to switch that display off.  There is even the possibility of
making its default nil.

> I'm not aware of any complaints about what happens when desktop.el
> restores a session (one more reason to consider your case a rare one).

We simply don't know how common it is.  It's the sort of phenomenon that
irritates, but not enough to be bothered to do anything about it.  I've
been irritated by it for quite some time, also irritated in previous
years by random buffers being displayed on my screen at startup without
understanding why.  Now I do understand why, and have made amendments to
my Emacs so that these things don't happen any more.

I was proposing to give users a choice between different sorts of
irritation.  I get irritated at indeterminate waits for something to
happen, you get irritated by half a minute's worth of a counter
incrementing on a screen.  I will solve my personal problem by
incorporating my changes into every current and future version of Emacs
on my machine.

> > What about the other remaining matter - that (message "") in info.el?
> > Presumably we're waiting on some response from Juri.

> Yes.  Assuming my guess is correct, I'm okay with removing that.

OK, thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 21 Oct 2022 19:01:52 +0000
> Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > If you want some messages to be displayed, you should be able to
> > sprinkle your init file with them, right?
> 
> No.  I want reassurance that my Emacs hasn't hung completely, and giving
> some indication of how long it's going to be busy is also wanted.  Random
> messages from .emacs won't help, here.
> 
> > You can also define a desktop-after-read-hook function to display
> > something, if you want.
> 
> I wasn't aware of this hook.  Being run just once at the end of
> desktop-read, it doesn't look like it can be used to provide any
> information about the progress of that desktop-read.

I think if you enable garbage-collection-messages in your init file,
you will see more traffic in the echo area.

I'm even okay with adding a hook after each buffer is restored, if
that will make you happy.  I just don't want these messages (or
anything similar) show by default, because no one wants them badly
enough.  desktop.el is a very old package, so people (myself included)
have been using it for decades without being irritated by these
problems.  It really is an irritation peculiar to your configuration
and your state of mind.  (There's nothing wrong about having peculiar
configurations and states of mind.)

> > Assuming this will make the frame display something, why impose your
> > personal preferences on everyone?
> 
> That's not fair.  One could make the same insinuation against anybody who
> added an option for users.

It isn't an "insinuation", it's a call to all of us to exercise some
self-restraint in imposing on all users solutions for problems that
are peculiar to our personal setups.

> > I'm not aware of any complaints about what happens when desktop.el
> > restores a session (one more reason to consider your case a rare one).
> 
> We simply don't know how common it is.  It's the sort of phenomenon that
> irritates, but not enough to be bothered to do anything about it.

We may not know how common the display issue is, but we do know how
common the irritation is: extremely uncommon, to say the least.

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

[Alan Mackenzie]

Hello, Eli.

On Fri, Oct 21, 2022 at 22:14:45 +0300, Eli Zaretskii wrote:
> > Date: Fri, 21 Oct 2022 19:01:52 +0000
> > Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > If you want some messages to be displayed, you should be able to
> > > sprinkle your init file with them, right?

> > No.  I want reassurance that my Emacs hasn't hung completely, and giving
> > some indication of how long it's going to be busy is also wanted.  Random
> > messages from .emacs won't help, here.

> > > You can also define a desktop-after-read-hook function to display
> > > something, if you want.

> > I wasn't aware of this hook.  Being run just once at the end of
> > desktop-read, it doesn't look like it can be used to provide any
> > information about the progress of that desktop-read.

> I think if you enable garbage-collection-messages in your init file,
> you will see more traffic in the echo area.

There's too little information (and too much irritation) from them.  One
will get the same GC messages from a looping major mode as from
successful desktop loading.

> I'm even okay with adding a hook after each buffer is restored, if
> that will make you happy.  I just don't want these messages (or
> anything similar) show by default, because no one wants them badly
> enough.

As a general principle:

    When an operation can take a while to finish, you should inform the
    user about the progress it makes.  This way the user can estimate
    remaining time and clearly see that Emacs is busy working, not hung.

[Emacs Lisp manual, page "Progress"]

> desktop.el is a very old package, so people (myself included)
> have been using it for decades without being irritated by these
> problems.

We really don't know this.  You haven't been irritated by it, I have, for
a long time.

> It really is an irritation peculiar to your configuration and your
> state of mind.  (There's nothing wrong about having peculiar
> configurations and states of mind.)

It's not peculiar to my configuration, this problem of indeterminate
length non-responsiveness can happen in any configuration.  As for my
state of mind, well ...... ;-)

> > > Assuming this will make the frame display something, why impose your
> > > personal preferences on everyone?

> > That's not fair.  One could make the same insinuation against anybody who
> > added an option for users.

> It isn't an "insinuation", it's a call to all of us to exercise some
> self-restraint in imposing on all users solutions for problems that
> are peculiar to our personal setups.

It is not peculiar to my setup.  It is a general problem.  Stefan Kangas
has posted that he holds a similar viewpoint to mine.

What is a mystery is how desktop.el could have survived so long without
the progress indication recommended by the Elisp manual.

> > > I'm not aware of any complaints about what happens when desktop.el
> > > restores a session (one more reason to consider your case a rare one).

> > We simply don't know how common it is.  It's the sort of phenomenon that
> > irritates, but not enough to be bothered to do anything about it.

> We may not know how common the display issue is, but we do know how
> common the irritation is: extremely uncommon, to say the least.

We do not know.  All we know is that few people have complained, possibly
in the same way that few people in tropical lands complain about buzzing
flies.  It would be interesting to see how many users would say "yes
please!" if given the option of this option.  I suspect it would be many
more than those who would take the trouble to complain about its lack.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 21 Oct 2022 20:11:12 +0000
> Cc: juri@linkov.net, 58634@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I'm even okay with adding a hook after each buffer is restored, if
> > that will make you happy.  I just don't want these messages (or
> > anything similar) show by default, because no one wants them badly
> > enough.
> 
> As a general principle:
> 
>     When an operation can take a while to finish, you should inform the
>     user about the progress it makes.  This way the user can estimate
>     remaining time and clearly see that Emacs is busy working, not hung.
> 
> [Emacs Lisp manual, page "Progress"]

In my configurations, desktop.el upholds that promise.

If you are unhappy even with the additional hook proposal (you didn't
say), then I guess we have nothing more to discuss here that could be
useful.

> What is a mystery is how desktop.el could have survived so long without
> the progress indication recommended by the Elisp manual.

Once again, when I restore my sessions, I see a flurry of messages
that inform me of what's going on.  And my sessions are very large, so
they take a relatively long time to restore.

There's nothing wrong with desktop.el per se, not in the common use
cases.

> > We may not know how common the display issue is, but we do know how
> > common the irritation is: extremely uncommon, to say the least.
> 
> We do not know.  All we know is that few people have complained

"Few" as in "none".

Again, this part of the discussion is not useful.  If an additional
hook could fulfill your needs, please feel free to install such a
change, and let's move on to more important stuff.

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Oct 22, 2022 at 09:26:14 +0300, Eli Zaretskii wrote:
> > Date: Fri, 21 Oct 2022 20:11:12 +0000
> > Cc: juri@linkov.net, 58634@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > I'm even okay with adding a hook after each buffer is restored, if
> > > that will make you happy.  I just don't want these messages (or
> > > anything similar) show by default, because no one wants them badly
> > > enough.

I want them.  Stefan Kangas wants them.  We don't know how many other
people want them, even amongst Emacs developers.  If you don't want the
messages enabled by default, why not include the facility disabled by
default, so that users can enable it when they do want it?

> > As a general principle:

> >     When an operation can take a while to finish, you should inform the
> >     user about the progress it makes.  This way the user can estimate
> >     remaining time and clearly see that Emacs is busy working, not hung.

> > [Emacs Lisp manual, page "Progress"]

> In my configurations, desktop.el upholds that promise.

Yours is an unusual configuration.  Most people don't hook up flyspell to
text modes, and surely even fewer enable GC messages.  But is that really
the reason for your unhappiness with my proposal?  That it isn't useful
for you personally?

> If you are unhappy even with the additional hook proposal (you didn't
> say), then I guess we have nothing more to discuss here that could be
> useful.

The additional hook is a red herring.  To be fully useful, it would need
to be passed the current filename and the total number of buffers being
restored.  That would involve more complicated code than is currently in
my patch (even if not by a lot).  Mainly, it would not be particularly
beneficial for users in general, unless you allowed me to include such a
hook function in desktop.el, which I suspect you would not.

> > What is a mystery is how desktop.el could have survived so long without
> > the progress indication recommended by the Elisp manual.

> Once again, when I restore my sessions, I see a flurry of messages
> that inform me of what's going on.

My sessions leave Emacs hung for a large portion of a minute, without
messages.  I suspect my configuration is nearer a typical one than yours
is.

> And my sessions are very large, so they take a relatively long time to
> restore.

> There's nothing wrong with desktop.el per se, not in the common use
> cases.

Clearly I disagree, here.

> > > We may not know how common the display issue is, but we do know how
> > > common the irritation is: extremely uncommon, to say the least.

> > We do not know.  All we know is that few people have complained

> "Few" as in "none".

I have complained.  Stefan Kangas was unhappy enough with the code that
he wrote his own patch, essentially the same as mine, to solve the
problem.  That's two people already.

> Again, this part of the discussion is not useful.

It was not me that introduced lack of complaint as a reason for not
improving Emacs.

> If an additional hook could fulfill your needs, please feel free to
> install such a change, and let's move on to more important stuff.

As above, this hook would be not useful to users in general, and be more
complicated than my current patch.  It would need documentation in the
Elisp manual.  It would not be very useful to me personally, either.  As
I said earlier, I'm incorporating my patch into all my personal versions
of Emacs from now on.

My new code is a clear improvement on the current desktop.el, and
fulfills a clear need.  No real disadvantages of it have yet been pointed
out.  It seems you are not going to allow this patch to be installed, yet
have given no plausible reason for that.  So be it.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sat, 22 Oct 2022 12:20:18 +0000
> Cc: juri@linkov.net, 58634@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Eli.
> 
> On Sat, Oct 22, 2022 at 09:26:14 +0300, Eli Zaretskii wrote:
> > > Date: Fri, 21 Oct 2022 20:11:12 +0000
> > > Cc: juri@linkov.net, 58634@debbugs.gnu.org
> > > From: Alan Mackenzie <acm@muc.de>
> 
> > > > I'm even okay with adding a hook after each buffer is restored, if
> > > > that will make you happy.  I just don't want these messages (or
> > > > anything similar) show by default, because no one wants them badly
> > > > enough.
> 
> I want them.  Stefan Kangas wants them.  We don't know how many other
> people want them, even amongst Emacs developers.  If you don't want the
> messages enabled by default, why not include the facility disabled by
> default, so that users can enable it when they do want it?

A hook I proposed is a more general facility, and can satisfy this
need as well.  It looks to me as a better solution.

> > If you are unhappy even with the additional hook proposal (you didn't
> > say), then I guess we have nothing more to discuss here that could be
> > useful.
> 
> The additional hook is a red herring.  To be fully useful, it would need
> to be passed the current filename and the total number of buffers being
> restored.

Since it's a hook called when restoring a buffer, it should be called
with the buffer name.  The total number of buffers is AFAIR known only
after everything is processed, and is stored in the
desktop-buffer-ok-count.  What else is missing?

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Oct 22, 2022 at 16:11:06 +0300, Eli Zaretskii wrote:
> > Date: Sat, 22 Oct 2022 12:20:18 +0000
> > Cc: juri@linkov.net, 58634@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Hello, Eli.

> > On Sat, Oct 22, 2022 at 09:26:14 +0300, Eli Zaretskii wrote:
> > > > Date: Fri, 21 Oct 2022 20:11:12 +0000
> > > > Cc: juri@linkov.net, 58634@debbugs.gnu.org
> > > > From: Alan Mackenzie <acm@muc.de>

> > > > > I'm even okay with adding a hook after each buffer is restored, if
> > > > > that will make you happy.  I just don't want these messages (or
> > > > > anything similar) show by default, because no one wants them badly
> > > > > enough.

> > I want them.  Stefan Kangas wants them.  We don't know how many other
> > people want them, even amongst Emacs developers.  If you don't want the
> > messages enabled by default, why not include the facility disabled by
> > default, so that users can enable it when they do want it?

> A hook I proposed is a more general facility, and can satisfy this
> need as well.  It looks to me as a better solution.

OK, I've implemented a solution with a hook.  First version of the patch
is below.

> > > If you are unhappy even with the additional hook proposal (you didn't
> > > say), then I guess we have nothing more to discuss here that could be
> > > useful.

> > The additional hook is a red herring.  To be fully useful, it would need
> > to be passed the current filename and the total number of buffers being
> > restored.

> Since it's a hook called when restoring a buffer, it should be called
> with the buffer name.  The total number of buffers is AFAIR known only
> after everything is processed, and is stored in the
> desktop-buffer-ok-count.  What else is missing?

The total number of buffers can be (and in my patch is) counted in
desktop-save and saved in .emacs.desktop.  It is reinstated in variable
desktop-buffer-count during desktop-read.

In the patch below, I've patterned the new progress messages after the
existing desktop-lazy messages.  Though I don't suppose the lazy loading
facility will be used too much nowadays, given how fast SSDs and
processors are.  All these messages are now output from the hook function.

(The patch is best viewed with git diff -b.)



diff --git a/lisp/desktop.el b/lisp/desktop.el
index ef73bc596d..71f34aa95d 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -319,6 +319,7 @@ desktop-save-hook
 
 (defcustom desktop-globals-to-save
   '(desktop-missing-file-warning
+    desktop-buffer-count
     tags-file-name
     tags-table-list
     search-ring
@@ -383,6 +384,11 @@ desktop-locals-to-save
   :type '(repeat symbol)
   :group 'desktop)
 
+(defcustom desktop-echo-progress t
+  "If non-nil, progress messages are displayed on loading the desktop."
+  :type 'boolean
+  :group 'desktop)
+
 (defcustom desktop-buffers-not-to-save "\\` "
   "Regexp identifying buffers that are to be excluded from saving.
 This is in effect only for buffers that don't visit files.
@@ -1086,6 +1092,9 @@ desktop-save-frameset
 			    :name (concat user-login-name "@" (system-name))
 			    :predicate #'desktop--check-dont-save))))
 
+(defvar desktop-buffer-count nil
+  "Number of buffers recorded in the desktop file.")
+
 ;;;###autoload
 (defun desktop-save (dirname &optional release only-if-changed version)
   "Save the state of Emacs in a desktop file in directory DIRNAME.
@@ -1108,7 +1117,7 @@ desktop-save
 
 To upgrade a version 206 file to version 208, call this command
 explicitly with a prefix argument: \\[universal-argument] \\[desktop-save].
-If you are upgrading from Emacs 24 or older, we recommend to do
+If you are upgrading from Emacs 24 or older, we recommend doing
 this once you decide you no longer need compatibility with versions
 of Emacs before 25.1.
 
@@ -1176,69 +1185,77 @@ desktop-save
                 desktop-io-file-version)))
 
 	(with-temp-buffer
-	  (insert
-	   ";; -*- mode: emacs-lisp; lexical-binding:t; coding: utf-8-emacs; -*-\n"
-	   desktop-header
-	   ";; Created " (current-time-string) "\n"
-	   ";; Desktop file format version " (format "%d" desktop-io-file-version) "\n"
-	   ";; Emacs version " emacs-version "\n")
-	  (save-excursion (run-hooks 'desktop-save-hook))
-	  (goto-char (point-max))
-	  (insert "\n;; Global section:\n")
-	  ;; Called here because we save the window/frame state as a global
-	  ;; variable for compatibility with previous Emacsen.
-	  (desktop-save-frameset)
-	  (unless (memq 'desktop-saved-frameset desktop-globals-to-save)
-	    (desktop-outvar 'desktop-saved-frameset))
-	  (mapc #'desktop-outvar desktop-globals-to-save)
-	  (setq desktop-saved-frameset nil) ; after saving desktop-globals-to-save
-	  (when (memq 'kill-ring desktop-globals-to-save)
-	    (insert
-	     "(setq kill-ring-yank-pointer (nthcdr "
-	     (int-to-string (- (length kill-ring) (length kill-ring-yank-pointer)))
-	     " kill-ring))\n"))
-
-	  (insert "\n;; Buffer section -- buffers listed in same order as in buffer list:\n")
-	  (dolist (l (mapcar #'desktop-buffer-info (buffer-list)))
-	    (let ((base (pop l)))
-	      (when (apply #'desktop-save-buffer-p l)
-		(insert "("
-			(if (or (not (integerp eager))
-				(if (zerop eager)
-				    nil
-				  (setq eager (1- eager))))
-			    "desktop-create-buffer"
-			  "desktop-append-buffer-args")
-			" "
-			(format "%d" desktop-io-file-version))
-		;; If there's a non-empty base name, we save it instead of the buffer name
-		(when (and base (not (string= base "")))
-		  (setcar (nthcdr 1 l) base))
-		(dolist (e l)
-		  (insert "\n  " (desktop-value-to-string e)))
-		(insert ")\n\n"))))
-
-	  (setq default-directory desktop-dirname)
-	  ;; When auto-saving, avoid writing if nothing has changed since the last write.
-	  (let* ((beg (and only-if-changed
-			   (save-excursion
-			     (goto-char (point-min))
-			     ;; Don't check the header with changing timestamp
-			     (and (search-forward "Global section" nil t)
-				  ;; Also skip the timestamp in desktop-saved-frameset
-				  ;; if it's saved in the first non-header line
-				  (search-forward "desktop-saved-frameset"
-						  (line-beginning-position 3) t)
-				  ;; This is saved after the timestamp
-				  (search-forward (format "%S" desktop--app-id) nil t))
-			     (point))))
-		 (checksum (and beg (md5 (current-buffer) beg (point-max) 'utf-8-emacs))))
-	    (unless (and checksum (equal checksum desktop-file-checksum))
-	      (let ((coding-system-for-write 'utf-8-emacs))
-		(write-region (point-min) (point-max) (desktop-full-file-name) nil 'nomessage))
-	      (setq desktop-file-checksum checksum)
-	      ;; We remember when it was modified (which is presumably just now).
-	      (desktop--get-file-modtime))))))))
+          (let ((desktop-buffer-count 0) global-pos)
+            (insert
+	     ";; -*- mode: emacs-lisp; lexical-binding:t; coding: utf-8-emacs; -*-\n"
+	     desktop-header
+	     ";; Created " (current-time-string) "\n"
+	     ";; Desktop file format version " (format "%d" desktop-io-file-version) "\n"
+	     ";; Emacs version " emacs-version "\n")
+	    (save-excursion (run-hooks 'desktop-save-hook))
+	    (goto-char (point-max))
+	    (insert "\n;; Global section:\n")
+	    ;; Called here because we save the window/frame state as a global
+	    ;; variable for compatibility with previous Emacsen.
+	    (desktop-save-frameset)
+            (setq global-pos (point)) ; Don't write the global section
+                                        ; till we've counted the buffers.
+
+	    (insert "\n;; Buffer section -- buffers listed in same order as in buffer list:\n")
+	    (dolist (l (mapcar #'desktop-buffer-info (buffer-list)))
+	      (let ((base (pop l)))
+	        (when (apply #'desktop-save-buffer-p l)
+                  (setq desktop-buffer-count (1+ desktop-buffer-count))
+		  (insert "("
+			  (if (or (not (integerp eager))
+				  (if (zerop eager)
+				      nil
+				    (setq eager (1- eager))))
+			      "desktop-create-buffer"
+			    "desktop-append-buffer-args")
+			  " "
+			  (format "%d" desktop-io-file-version))
+		  ;; If there's a non-empty base name, we save it instead of the buffer name
+		  (when (and base (not (string= base "")))
+		    (setcar (nthcdr 1 l) base))
+		  (dolist (e l)
+		    (insert "\n  " (desktop-value-to-string e)))
+		  (insert ")\n\n"))))
+
+            (goto-char global-pos)
+	    (unless (memq 'desktop-saved-frameset desktop-globals-to-save)
+	      (desktop-outvar 'desktop-saved-frameset))
+            (unless (memq 'desktop-buffer-count desktop-globals-to-save)
+              (desktop-outvar 'desktop-buffer-count))
+	    (mapc #'desktop-outvar desktop-globals-to-save)
+	    (setq desktop-saved-frameset nil) ; after saving desktop-globals-to-save
+	    (when (memq 'kill-ring desktop-globals-to-save)
+	      (insert
+	       "(setq kill-ring-yank-pointer (nthcdr "
+	       (int-to-string (- (length kill-ring) (length kill-ring-yank-pointer)))
+	       " kill-ring))\n"))
+
+	    (setq default-directory desktop-dirname)
+	    ;; When auto-saving, avoid writing if nothing has changed since the last write.
+	    (let* ((beg (and only-if-changed
+			     (save-excursion
+			       (goto-char (point-min))
+			       ;; Don't check the header with changing timestamp
+			       (and (search-forward "Global section" nil t)
+				    ;; Also skip the timestamp in desktop-saved-frameset
+				    ;; if it's saved in the first non-header line
+				    (search-forward "desktop-saved-frameset"
+						    (line-beginning-position 3) t)
+				    ;; This is saved after the timestamp
+				    (search-forward (format "%S" desktop--app-id) nil t))
+			       (point))))
+		   (checksum (and beg (md5 (current-buffer) beg (point-max) 'utf-8-emacs))))
+	      (unless (and checksum (equal checksum desktop-file-checksum))
+	        (let ((coding-system-for-write 'utf-8-emacs))
+		  (write-region (point-min) (point-max) (desktop-full-file-name) nil 'nomessage))
+	        (setq desktop-file-checksum checksum)
+	        ;; We remember when it was modified (which is presumably just now).
+	        (desktop--get-file-modtime)))))))))
 
 ;; ----------------------------------------------------------------------------
 ;;;###autoload
@@ -1293,6 +1310,36 @@ desktop-first-buffer
 (defvar desktop-buffer-ok-count)
 (defvar desktop-buffer-fail-count)
 
+(defun desktop-progress-message (buffer-name &optional success)
+  "Display a message about the buffer being restored by desktop.
+BUFFER-NAME, a string, is the name of the buffer.  SUCCESS is
+nil (absent) when we haven't yet restored the buffer, `t' when
+the buffer has been successfully restored, `fail' otherwise."
+  (message "") ; Make sure we have just one line in the echo area.
+  (if (boundp 'desktop-buffer-ok-count)
+      ;; in the "normal" restoration.
+      (when (not success)
+        (message
+         "Desktop opening %-30s (%s remaining)"
+         buffer-name
+         (if desktop-buffer-count
+             (- desktop-buffer-count
+                desktop-buffer-ok-count
+                desktop-buffer-fail-count 1)
+           "???")))
+    ;; In lazy restoration.
+    (message
+     "Desktop lazily opening %s%s"
+     buffer-name
+     (if (boundp 'desktop-buffer-args-list)
+         (format " (%s remaining)...%s"
+                 (length desktop-buffer-args-list)
+                 (cond
+                  ((null success) "")
+                  ((eq success t) "done")
+                  (t "failed")))
+       ""))))
+
 ;;;###autoload
 (defun desktop-read (&optional dirname ask)
   "Read and process the desktop file in directory DIRNAME.
@@ -1358,11 +1405,19 @@ desktop-read
                         ;; buffer-local, and puts there stuff which
                         ;; doesn't include our timer.
                         (default-value
-                          'window-configuration-change-hook)))
+                         'window-configuration-change-hook)))
 	    (desktop-auto-save-disable)
 	    ;; Evaluate desktop buffer and remember when it was modified.
 	    (desktop--get-file-modtime)
+            ;; Enable progress reporting.....
+            (when desktop-echo-progress
+              (add-hook 'desktop-open-buffer-functions
+                        'desktop-progress-message))
 	    (load (desktop-full-file-name) t t t)
+            ;; .... and disable it again.
+            (when desktop-echo-progress
+              (remove-hook 'desktop-open-buffer-functions
+                           'desktop-progress-message))
 	    ;; If it wasn't already, mark it as in-use, to bother other
 	    ;; desktop instances.
 	    (unless (eq (emacs-pid) owner)
@@ -1398,6 +1453,7 @@ desktop-read
 			 (format ", %d to restore lazily"
 				 (length desktop-buffer-args-list))
 		       ""))
+            (sit-for 3)
 	    (unless (desktop-restoring-frameset-p)
 	      ;; Bury the *Messages* buffer to not reshow it when burying
 	      ;; the buffer we switched to above.
@@ -1544,6 +1600,16 @@ desktop-load-file
           (with-demoted-errors "Require error in desktop-load-file: %S"
               (require (intern (match-string 1 name)) nil t))))))
 
+(defvar desktop-open-buffer-functions nil
+  "Abnormal hook called before and after creating a buffer's file in desktop.
+When called before creating the buffer, it is given one argument,
+the name of the buffer being restored.  When called after
+attempting to create the buffer, it is additionally given a
+second argument with value `t' when the creation was successful,
+`fail' otherwise.
+
+It's return value has no significance.")
+
 ;; ----------------------------------------------------------------------------
 ;; Create a buffer, load its file, set its mode, ...;
 ;; called from Desktop file only.
@@ -1575,6 +1641,7 @@ desktop-create-buffer
 	(desktop-buffer-read-only   buffer-readonly)
 	(desktop-buffer-misc	    buffer-misc)
 	(desktop-buffer-locals	    buffer-locals))
+    (run-hook-with-args 'desktop-open-buffer-functions desktop-buffer-name)
     ;; To make desktop files with relative file names possible, we cannot
     ;; allow `default-directory' to change. Therefore we save current buffer.
     (save-current-buffer
@@ -1595,9 +1662,15 @@ desktop-create-buffer
 			 (error-message-string err))
 		(when desktop-missing-file-warning (sit-for 1))
 		nil))))
-	(if (bufferp result)
-	    (setq desktop-buffer-ok-count (1+ desktop-buffer-ok-count))
-	  (setq desktop-buffer-fail-count (1+ desktop-buffer-fail-count))
+        (run-hook-with-args 'desktop-open-buffer-functions
+                            desktop-buffer-name
+                            (if (bufferp result) t 'fail))
+
+        (if (bufferp result)
+	    (when (boundp 'desktop-buffer-ok-count)
+              (setq desktop-buffer-ok-count (1+ desktop-buffer-ok-count)))
+          (when (boundp 'desktop-buffer-fail-count)
+	    (setq desktop-buffer-fail-count (1+ desktop-buffer-fail-count)))
 	  (setq result nil))
 	;; Restore buffer list order with new buffer at end. Don't change
 	;; the order for old desktop files (old desktop module behavior).
@@ -1698,22 +1771,18 @@ desktop-append-buffer-args
 (defun desktop-lazy-create-buffer ()
   "Pop args from `desktop-buffer-args-list', create buffer and bury it."
   (when desktop-buffer-args-list
-    (let* ((remaining (length desktop-buffer-args-list))
-           (args (pop desktop-buffer-args-list))
-           (buffer-name (nth 2 args))
-           (msg (format "Desktop lazily opening %s (%s remaining)..."
-                            buffer-name remaining)))
+    (let* ((args (pop desktop-buffer-args-list))
+           (buffer-name (nth 2 args)))
       (when desktop-lazy-verbose
-        (message "%s" msg))
-      (let ((desktop-first-buffer nil)
-            (desktop-buffer-ok-count 0)
-            (desktop-buffer-fail-count 0))
+        (add-hook 'desktop-open-buffer-functions 'desktop-progress-message))
+      (let* ((desktop-first-buffer nil))
         (apply #'desktop-create-buffer args)
+        (when desktop-lazy-verbose
+          (remove-hook 'desktop-open-buffer-functions
+                       'desktop-progress-message))
         (run-hooks 'desktop-delay-hook)
         (setq desktop-delay-hook nil)
-        (bury-buffer (get-buffer buffer-name))
-        (when desktop-lazy-verbose
-          (message "%s%s" msg (if (> desktop-buffer-ok-count 0) "done" "failed")))))))
+        (bury-buffer (get-buffer buffer-name))))))
 
 (defun desktop-idle-create-buffers ()
   "Create buffers until the user does something, then stop.



-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sun, 23 Oct 2022 15:22:05 +0000
> Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> > A hook I proposed is a more general facility, and can satisfy this
> > need as well.  It looks to me as a better solution.
> 
> OK, I've implemented a solution with a hook.

It doesn't seem to be such a solution.  I see the hook you've added,
but I also see desktop-echo-progress and desktop-progress-message.
Why are those here?  Why is anything needed in addition to the hook
and its calls where appropriate?

My suggestion was to add the hook, and that's it.

> The total number of buffers can be (and in my patch is) counted in
> desktop-save and saved in .emacs.desktop.

That means incompatible change of the desktop file format.  Let's not
do this, please, not for such unimportant reasons.

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

[Alan Mackenzie]

Hello, Eli.

On Sun, Oct 23, 2022 at 19:23:48 +0300, Eli Zaretskii wrote:
> > Date: Sun, 23 Oct 2022 15:22:05 +0000
> > Cc: juri@linkov.net, 58634@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > A hook I proposed is a more general facility, and can satisfy this
> > > need as well.  It looks to me as a better solution.

> > OK, I've implemented a solution with a hook.

> It doesn't seem to be such a solution.  I see the hook you've added,
> but I also see desktop-echo-progress and desktop-progress-message.
> Why are those here?  Why is anything needed in addition to the hook
> and its calls where appropriate?

What's the point of the hook on its own?  I can't see much.  I think what
you're suggesting is that every user who wants progress messages should
have to implement his own version.  That would be a tremendous waste of
hackers' time, and is, quite frankly, a ludicrous idea.  Besides, the
variable desktop-buffer-count is essential to full progress messages, and
it's scarcely clean programming for random hook functions to access it.

> My suggestion was to add the hook, and that's it.

I was hoping that wasn't what you meant.  I honestly can't see the point
in just the hook.  If you want this hook, feel free to extract it from my
patch.  I'm not willing to put any more time into this.

> > The total number of buffers can be (and in my patch is) counted in
> > desktop-save and saved in .emacs.desktop.

> That means incompatible change of the desktop file format.

Not at all.  desktop has the facility of dumping random variables into
..emacs.desktop, and there's even a customisable variable for this.  In
this case an extra

    (setq desktop-buffer-count 166)

gets written into the file, alongside several similar ones.

> Let's not do this, please, not for such unimportant reasons.

It's not unimportant.  This facility of progress messages is a needed
enhancement, without known disadvantages.  You're not willing to merge it
into Emacs, but haven't given a valid reason why not.

I'm not willing to continue fighting you.  I will probably post my
original patch to emacs-devel in a day or two, and then we can see just
what sort of demand for it there is amongst Emacs developers.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sun, 23 Oct 2022 18:58:42 +0000
> Cc: juri@linkov.net, 58634@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > OK, I've implemented a solution with a hook.
> 
> > It doesn't seem to be such a solution.  I see the hook you've added,
> > but I also see desktop-echo-progress and desktop-progress-message.
> > Why are those here?  Why is anything needed in addition to the hook
> > and its calls where appropriate?
> 
> What's the point of the hook on its own?  I can't see much.  I think what
> you're suggesting is that every user who wants progress messages should
> have to implement his own version.

Exactly.

> That would be a tremendous waste of
> hackers' time, and is, quite frankly, a ludicrous idea.

I don't think it's ludicrous, and I don't think it will be a waste,
for those few who want these progress reports.  How is it a problem to
show an echo-area message saying something like "Restoring buffer %s"?

> Besides, the
> variable desktop-buffer-count is essential to full progress messages

If that is a running count of buffers, the hook can count by itself:
again, a trivial one-liner.  If that's the total number of buffers in
the list, finding their number is a matter of calling 'length'.

(Not that I really understand why the count is so important.  Your
complaint was that Emacs looks frozen, in which case just showing
messages in the echo-area will go a long way towards making clear it
isn't frozen.  So the count and any kind of "progress report" doesn't
sound very important.  But if it is, doing that in a hook should be
easy enough.)

So I really don't see what is all the fuss here.  I suggested a simple
solution for a problem that evidently affects very few.  Since when
writing a short hook function is deemed a problem for someone with
your experience?  Don't you have hooks in your init files?

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

[Alan Mackenzie]

Hello, Eli.

On Sun, Oct 23, 2022 at 22:11:16 +0300, Eli Zaretskii wrote:

[ .... ]

I've closed the bug as wontfix.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Wed, 26 Oct 2022 16:35:18 +0000
> Cc: juri@linkov.net, 58634@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I've closed the bug as wontfix.

Thanks.

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

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

> I've closed the bug as wontfix.

That's unfortunate.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 26 Oct 2022 12:39:22 -0700
> Cc: 58634@debbugs.gnu.org, juri@linkov.net
> 
> Alan Mackenzie <acm@muc.de> writes:
> 
> > I've closed the bug as wontfix.
> 
> That's unfortunate.

If you (or someone else) want to work on adding the hook I suggested,
I'm still fine with having it added.

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

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Alan Mackenzie <acm@muc.de> writes:

> My current idea is to count the buffers in desktop-save, and to output a
> message:
>
>     Restoring buffers: 127/166
>
> as we restore the buffers.  We already count the buffers as we load
> them.

Yes, this would be useful.  It is bad to not see any progress while the
desktop is loading, for several reasons.  One of them is that you
usually expect to see some kind of indication of progress during
long-running operations.

I wrote up some code to show such a counter myself about a year and a
half ago, and I'm attaching the patch here in case it is of any help.
Maybe you could take some inspiration from it Alan, or maybe not.

I honestly can't remember why I didn't propose it back then.  Maybe I
felt like it should be possible to find a more elegant solution?  I
can't remember.  In any case, if the patch still applies it should at
the very least work, I hope.

[-- Attachment #2: 0001-New-option-to-show-progress-as-desktop-file-loads.patch --]
[-- Type: text/x-diff, Size: 3637 bytes --]

From eb94b5598b102290cccf6aee70182100e861dff5 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Sun, 26 Jan 2020 08:41:53 +0100
Subject: [PATCH] New option to show progress as desktop file loads

* lisp/desktop.el (desktop-save-adds-progress-reporter): New option.
(desktop-save): Save a 'progress-reporter' into the desktop file if
the above option is non-nil.
* etc/NEWS: Announce the above option.
---
 etc/NEWS        |  6 ++++++
 lisp/desktop.el | 37 +++++++++++++++++++++++++++++++------
 2 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index c3a71ade8a..fa27431245 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -87,6 +87,12 @@ line numbers that were previously jumped to.
 \f
 * Changes in Specialized Modes and Packages in Emacs 28.1
 
+** Desktop
+
+*** New option to show progress as desktop file loads.
+Customize the new user option 'desktop-save-adds-progress-reporter' to
+enable it. Read the documentation of that option for more details.
+
 ---
 ** The sb-image.el library is now marked obsolete.
 This file was a compatibility kludge which is no longer needed.
diff --git a/lisp/desktop.el b/lisp/desktop.el
index 9538bb4a34..b634fcbca4 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -306,6 +306,20 @@ desktop-save-hook
   :type 'hook
   :group 'desktop)
 
+(defcustom desktop-save-adds-progress-reporter nil
+  "If non-nil, add a progress reporter to saved desktop files.
+This can be used to show progress while a desktop file is
+loading.
+
+Note that this will not take effect until you run `desktop-save'
+at least once with this option enabled, and then `desktop-load'
+that saved file.
+
+Once a desktop file has had been saved with progress reporters,
+it is on unconditionally on subsequent loads of that file."
+  :type 'boolean
+  :version "28.1")
+
 (defcustom desktop-globals-to-save
   '(desktop-missing-file-warning
     tags-file-name
@@ -1113,11 +1127,17 @@ desktop-save
 	     (int-to-string (- (length kill-ring) (length kill-ring-yank-pointer)))
 	     " kill-ring))\n"))
 
-	  (insert "\n;; Buffer section -- buffers listed in same order as in buffer list:\n")
-	  (dolist (l (mapcar #'desktop-buffer-info (buffer-list)))
-	    (let ((base (pop l)))
-	      (when (apply #'desktop-save-buffer-p l)
-		(insert "("
+          (let ((buffers (seq-filter (lambda (l) (apply #'desktop-save-buffer-p (cdr l)))
+                                     (mapcar #'desktop-buffer-info (buffer-list))))
+                (i 0))
+	    (insert "\n;; Buffer section -- buffers listed in same order as in buffer list:\n")
+            (when desktop-save-adds-progress-reporter
+              (insert "(let ((reporter\n")
+              (insert (format "       (make-progress-reporter \"Restoring buffers...\" %s %s )))\n\n"
+                              0 (length buffers))))
+            (dolist (l buffers)
+	      (let ((base (pop l)))
+	        (insert "("
 			(if (or (not (integerp eager))
 				(if (zerop eager)
 				    nil
@@ -1131,7 +1151,12 @@ desktop-save
 		  (setcar (nthcdr 1 l) base))
 		(dolist (e l)
 		  (insert "\n  " (desktop-value-to-string e)))
-		(insert ")\n\n"))))
+		(insert ")\n")
+                (when desktop-save-adds-progress-reporter
+                  (setq i (1+ i))
+                  (insert (format "  (progress-reporter-update reporter %s)\n\n" i)))))
+            (when desktop-save-adds-progress-reporter
+              (insert "(progress-reporter-done reporter))\n")))
 
 	  (setq default-directory desktop-dirname)
 	  ;; When auto-saving, avoid writing if nothing has changed since the last write.
-- 
2.35.1

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

[Juri Linkov]

>> 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.
>
> I'm guessing that (message "") was there because originally that
> function was showing progress messages as part of its processing:
>
>    (or main-file (message "Searching subfile %s..." (car subfiles)))
>
> However, this has been commented out 14 years ago, so perhaps nowadays
> it isn't necessary.  Adding Juri to the CC in case he has some
> comments.

Indeed, it should have been removed together with the above message.
So now it's removed.

But it's surprising that loading desktop can be easily broken just
with a message.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Alan Mackenzie <acm@muc.de>,  58634@debbugs.gnu.org
> Date: Sat, 22 Oct 2022 20:46:50 +0300
> 
> >> 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.
> >
> > I'm guessing that (message "") was there because originally that
> > function was showing progress messages as part of its processing:
> >
> >    (or main-file (message "Searching subfile %s..." (car subfiles)))
> >
> > However, this has been commented out 14 years ago, so perhaps nowadays
> > it isn't necessary.  Adding Juri to the CC in case he has some
> > comments.
> 
> Indeed, it should have been removed together with the above message.
> So now it's removed.
> 
> But it's surprising that loading desktop can be easily broken just
> with a message.

I don't think this message breaks anything, it just changes whether
and how Emacs redisplays during restoring the desktop.

Thanks.