From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 58634@debbugs.gnu.org, juri@linkov.net
Subject: bug#58634: Long delay with blank screen whilst loading desktop at emacs startup
Date: Sat, 22 Oct 2022 12:20:18 +0000 [thread overview]
Message-ID: <Y1PgAkN6O3CJGrJA@ACM> (raw)
In-Reply-To: <83h6zwv0ft.fsf@gnu.org>
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).
next prev parent reply other threads:[~2022-10-22 12:20 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 13:28 bug#58634: Long delay with blank screen whilst loading desktop at emacs startup Alan Mackenzie
2022-10-19 15:49 ` Eli Zaretskii
2022-10-19 19:11 ` Andrea Corallo
2022-10-19 19:58 ` Alan Mackenzie
2022-10-20 5:20 ` Eli Zaretskii
2022-10-20 10:55 ` Alan Mackenzie
2022-10-20 13:07 ` Eli Zaretskii
2022-10-20 15:28 ` Alan Mackenzie
2022-10-20 16:28 ` Eli Zaretskii
2022-10-21 8:59 ` Alan Mackenzie
2022-10-21 11:28 ` Eli Zaretskii
2022-10-21 12:40 ` Alan Mackenzie
2022-10-21 13:22 ` Eli Zaretskii
2022-10-21 14:15 ` Alan Mackenzie
2022-10-21 15:23 ` Eli Zaretskii
2022-10-21 15:42 ` Alan Mackenzie
2022-10-21 15:57 ` Eli Zaretskii
2022-10-21 17:15 ` Alan Mackenzie
2022-10-21 18:12 ` Eli Zaretskii
2022-10-21 19:01 ` Alan Mackenzie
2022-10-21 19:14 ` Eli Zaretskii
2022-10-21 20:11 ` Alan Mackenzie
2022-10-22 6:26 ` Eli Zaretskii
2022-10-22 12:20 ` Alan Mackenzie [this message]
2022-10-22 13:11 ` Eli Zaretskii
2022-10-23 15:22 ` Alan Mackenzie
2022-10-23 16:23 ` Eli Zaretskii
2022-10-23 18:58 ` Alan Mackenzie
2022-10-23 19:11 ` Eli Zaretskii
2022-10-26 16:35 ` Alan Mackenzie
2022-10-26 16:38 ` Eli Zaretskii
2022-10-26 19:39 ` Stefan Kangas
2022-10-27 5:19 ` Eli Zaretskii
2022-10-21 19:09 ` Stefan Kangas
2022-10-22 17:46 ` Juri Linkov
2022-10-22 18:33 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1PgAkN6O3CJGrJA@ACM \
--to=acm@muc.de \
--cc=58634@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.