From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: acm@muc.de, 58634@debbugs.gnu.org
Subject: bug#58634: Long delay with blank screen whilst loading desktop at emacs startup
Date: Fri, 21 Oct 2022 08:59:58 +0000 [thread overview]
Message-ID: <Y1JfjvQm4n4u5/kO@ACM> (raw)
In-Reply-To: <83zgdqwjca.fsf@gnu.org>
Hello, Eli.
On Thu, Oct 20, 2022 at 19:28:05 +0300, Eli Zaretskii wrote:
> > Date: Thu, 20 Oct 2022 15:28:48 +0000
> > Cc: akrl@sdf.org, 58634@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>
> > > Because once redisplay is triggered, it runs to completion, whether
> > > it's "slow" or not. So if redisplay doesn't happen in one case it
> > > means it wasn't triggered. Things that trigger redisplay are calls to
> > > 'message', to 'sit-for', explicit call to 'redisplay', and some others.
> > I am puzzled by what is triggering the redisplay at all. Redisplay will
> > happen when "Emacs is waiting for input"
> Or when triggered by specific API calls I mentioned above.
> > but that means solely keyboard and mouse input, doesn't it?
> Also window-system events.
> > It doesn't mean file system input, does it?
> No, not if you mean "normal" file I/O (as opposed to, say, inotify).
OK, thanks.
> > So once Emacs starts the desktop loading with a call to `load', there
> > would appear to be nothing (in my setup, not yours) to trigger redisplay
> > until the load is complete. But it happens in a GUI Emacs and sometimes
> > in a tty Emacs. It happened for me on the linux console when I rebuilt
> > my Emacs 29 without native compilation; I got, IIRC, two buffers
> > displayed.
> That's exactly what needs to be explained: what triggers redisplay in
> the GUI session and why doesn't it happen in the -nw session?
I've found out quite a lot since yesterday. What's happening is this:
(i) desktop loads an info file from .emacs.desktop.
(ii) desktop calls the Info-mode handler, Info-restore-desktop-buffer in
info.el.
(iii) Eventually, the stack of calls reaches Info-toc-build. This
function calls (message "").
(iv) (message "") clears the echo area AND RESIZES IT IF NEEDED.
(v) The resizing of the echo area causes the main window to be
redisplayed.
(vi) Since the window-buffer of the main window hasn't yet been set to
the new info buffer, redisplay displays the buffer from the PREVIOUS
call to desktop-create-buffer.
So it's that (message "") which is triggering redisplay.
The call to (message "") in Info-toc-build must be a bug. This function
has no business doing anything in the echo area, its purpose being to
generate a table of contents. I think it's likely that this is what
erases desktop's message about having visited .emacs.desktop.
I think that my GUI session was displaying more buffers because its frame
is narrower, hence more messages in the echo area needed two lines. Thus
more info buffers caused the resizing of the echo area.
> > > > If you agree with me that this needs fixing (I think you do), I have two
> > > > ideas on how to fix it:
> > > I don't yet see what is the problem we are supposed to fix here. Even
> > > if, after we dig deeper into this and understand why the frame stays
> > > blank in the console case, why is that a problem that needs fixing?
> > Because it looks, for an extended period of time, like Emacs has hung
> > completely.
> That just takes getting used to.
I've got used to it. I still say it's a bad thing. Somebody whose
..emacs.desktop contains no info files and doesn't do things like calling
flyspell will see Emacs hang for a long time.
> And anyway, let's postpone this part of the discussion until we
> understand what happens in the -nw session that makes it behave
> differently. because we are talking about a phenomenon we don't
> understand well enough.
> > This is going to irritate people, and might prompt some users to
> > abort Emacs. If it can be 18 seconds blank screen for me, it could
> > easily be 2 minutes for somebody else with a larger desktop file or
> > a slower machine.
> 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.
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.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2022-10-21 8:59 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 [this message]
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
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=Y1JfjvQm4n4u5/kO@ACM \
--to=acm@muc.de \
--cc=58634@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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.