From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#58634: Long delay with blank screen whilst loading desktop at emacs startup Date: Fri, 21 Oct 2022 08:59:58 +0000 Message-ID: References: <83edv3zud8.fsf@gnu.org> <837d0vyssv.fsf@gnu.org> <83czamy76j.fsf@gnu.org> <83zgdqwjca.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19824"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 58634@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 21 12:12:29 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1olp0u-0004rO-Ei for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Oct 2022 12:12:28 +0200 Original-Received: from localhost ([::1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olp0r-0006mS-FS for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Oct 2022 06:12:26 -0400 Original-Received: from [::1] (helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olnuG-0000rh-Ii for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Oct 2022 05:01:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1olntq-0000Yp-Nd for bug-gnu-emacs@gnu.org; Fri, 21 Oct 2022 05:01:19 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1olntm-0006Pl-Uq for bug-gnu-emacs@gnu.org; Fri, 21 Oct 2022 05:01:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1olntm-0004GR-2J for bug-gnu-emacs@gnu.org; Fri, 21 Oct 2022 05:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Oct 2022 09:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58634 X-GNU-PR-Package: emacs Original-Received: via spool by 58634-submit@debbugs.gnu.org id=B58634.166634280916301 (code B ref 58634); Fri, 21 Oct 2022 09:01:02 +0000 Original-Received: (at 58634) by debbugs.gnu.org; 21 Oct 2022 09:00:09 +0000 Original-Received: from localhost ([127.0.0.1]:36997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1olnsu-0004Eq-E5 for submit@debbugs.gnu.org; Fri, 21 Oct 2022 05:00:08 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:38084) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1olnsr-0004Ci-RW for 58634@debbugs.gnu.org; Fri, 21 Oct 2022 05:00:06 -0400 Original-Received: (qmail 55684 invoked by uid 3782); 21 Oct 2022 10:59:59 +0200 Original-Received: from acm.muc.de (p4fe15b9b.dip0.t-ipconnect.de [79.225.91.155]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 21 Oct 2022 10:59:58 +0200 Original-Received: (qmail 4444 invoked by uid 1000); 21 Oct 2022 08:59:58 -0000 Content-Disposition: inline In-Reply-To: <83zgdqwjca.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:245977 Archived-At: 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 > > > 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).