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: Sun, 23 Oct 2022 18:58:42 +0000

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





reply via email to

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