all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Fri, 21 Oct 2022 20:11:12 +0000	[thread overview]
Message-ID: <Y1L84BbLQV0tKbFN@ACM> (raw)
In-Reply-To: <83lep9ugyi.fsf@gnu.org>

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





  reply	other threads:[~2022-10-21 20:11 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 [this message]
2022-10-22  6:26                                           ` Eli Zaretskii
2022-10-22 12:20                                             ` Alan Mackenzie
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=Y1L84BbLQV0tKbFN@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.