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: Thu, 20 Oct 2022 15:28:48 +0000 Message-ID: References: <83edv3zud8.fsf@gnu.org> <837d0vyssv.fsf@gnu.org> <83czamy76j.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="24933"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 58634@debbugs.gnu.org, akrl@sdf.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 20 17:40:10 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 1olXeT-0006KI-SY for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Oct 2022 17:40:09 +0200 Original-Received: from localhost ([::1]:42764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olXeR-0002i5-Df for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Oct 2022 11:40:07 -0400 Original-Received: from [::1] (helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olXYw-00009F-Hv for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 20 Oct 2022 11:34:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55048) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1olXTk-00085Z-9K for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2022 11:29:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36896) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1olXTj-0003rp-0q for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2022 11:29:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1olXTh-0003mf-Lp for bug-gnu-emacs@gnu.org; Thu, 20 Oct 2022 11:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Oct 2022 15:29:01 +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.166627973814536 (code B ref 58634); Thu, 20 Oct 2022 15:29:01 +0000 Original-Received: (at 58634) by debbugs.gnu.org; 20 Oct 2022 15:28:58 +0000 Original-Received: from localhost ([127.0.0.1]:35974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1olXTe-0003mO-1W for submit@debbugs.gnu.org; Thu, 20 Oct 2022 11:28:58 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]:37223) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1olXTb-0003m9-Tp for 58634@debbugs.gnu.org; Thu, 20 Oct 2022 11:28:56 -0400 Original-Received: (qmail 2519 invoked by uid 3782); 20 Oct 2022 17:28:49 +0200 Original-Received: from acm.muc.de (p4fe15bc5.dip0.t-ipconnect.de [79.225.91.197]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 20 Oct 2022 17:28:48 +0200 Original-Received: (qmail 1773 invoked by uid 1000); 20 Oct 2022 15:28:48 -0000 Content-Disposition: inline In-Reply-To: <83czamy76j.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:245937 Archived-At: Hello, Eli. On Thu, Oct 20, 2022 at 16:07:48 +0300, Eli Zaretskii wrote: > > Date: Thu, 20 Oct 2022 10:55:40 +0000 > > Cc: akrl@sdf.org, 58634@debbugs.gnu.org, acm@muc.de > > From: Alan Mackenzie > > > Because with Emacs 28 I use desktop.el all the time, and I do see the > > > frame displaying some files and messages in the echo-area. > > Remember, the blank screen only happens for me in emacs -nw and on the > > linux console, not in GUI X. > This has yet to be explained. See below. Yes. > > > If the same happens for you with Emacs 28, I guess it's somehow > > > related to your init files and/or what exactly is in your session. > > > For example, my sessions always include some buffers under Text mode > > > or its descendants, and those turn on Flyspell mode in my > > > configuration; starting Flyspell mode launches the speller as a > > > sub-process, and that usually triggers some form of redisplay. In > > > addition, I have garbage-collection-messages turned on, so GC-related > > > messages are shown in the echo-area, which also is a kind of > > > redisplay. Restoring file buffers sometimes produces prompts, e.g. if > > > the file is too large or there are local variables there that require > > > confirmation -- and those prompts trigger redisplay as well. > > > If you have none of that in your configuration, perhaps desktop.el can > > > indeed produce a completely blank frame. Although it sounds strange > > > to me, since I never saw anything like that. But it could be because > > > I'm used to starting Emacs with my configuration. > > All this supports my hypothesis (above). Anything which is "slow" > > causes a redisplay during desktop loading. For each buffer loaded, > > there is a switch-to-buffer call, so anything causing a redisplay will > > display that buffer. > I don't follow this reasoning. Emacs is a single-threaded program, so > redisplay or lack thereof cannot be explained by something being > "slow". I suppose it's more an observation (from instrumentation of the desktop loading) than an explanation. When a buffer takes longer than usual to be read, the previous buffer sometimes gets displayed. > 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", but that means solely keyboard and mouse input, doesn't it? It doesn't mean file system input, does it? 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. > > 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. 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. -- Alan Mackenzie (Nuremberg, Germany).