bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alan Mackenzie
Subject: bug#58634: Long delay with blank screen whilst loading desktop at emacs startup
Date: Fri, 21 Oct 2022 12:40:32 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]