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: Sat, 22 Oct 2022 12:20:18 +0000

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





reply via email to

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