From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Alexander Shukaev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2017 00:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 29095@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.150949710715201 (code B ref -1); Wed, 01 Nov 2017 00:46:01 +0000 Received: (at submit) by debbugs.gnu.org; 1 Nov 2017 00:45:07 +0000 Received: from localhost ([127.0.0.1]:44789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9h9W-0003x6-VV for submit@debbugs.gnu.org; Tue, 31 Oct 2017 20:45:07 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53231) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9h9V-0003wM-Oj for submit@debbugs.gnu.org; Tue, 31 Oct 2017 20:45:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9h9P-0003Dg-OA for submit@debbugs.gnu.org; Tue, 31 Oct 2017 20:45:00 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55758) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e9h9P-0003Da-L0 for submit@debbugs.gnu.org; Tue, 31 Oct 2017 20:44:59 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9h9O-0005xb-G4 for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2017 20:44:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9h9L-0003Cy-Cl for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2017 20:44:58 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:46481) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e9h9L-0003CZ-6H for bug-gnu-emacs@gnu.org; Tue, 31 Oct 2017 20:44:55 -0400 X-Originating-IP: 88.68.190.226 Received: from [192.168.2.109] (dslb-088-068-190-226.088.068.pools.vodafone-ip.de [88.68.190.226]) (Authenticated sender: forum@alexander.shukaev.name) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id F40734048E for ; Wed, 1 Nov 2017 01:44:50 +0100 (CET) From: Alexander Shukaev Message-ID: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> Date: Wed, 1 Nov 2017 01:44:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hi, Decided to try pretest of 26.0.90 and immediately discovered that it is slower than, for example, 'e7f65187580342171dd9ad32e570c50c96badb13' which I used before. In particular, thanks to a couple of hours of bisecting, I found that the '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s, which is unacceptable. I have no idea how this made it's way to the 'master' branch. Furthermore, other operations like navigation across windows or performing an incremental search are also noticeably slower, i.e. they stutter annoyingly, and from what I see is a result of extensive GC spam which did not occur in previous versions. Looks like something core has really been changed and potentially broken. This needs investigation; let me know what can I do for you guys from my side. Thanks. Regards, Alexander From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2017 01:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alexander Shukaev Cc: 29095@debbugs.gnu.org Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.150949987919476 (code B ref 29095); Wed, 01 Nov 2017 01:32:02 +0000 Received: (at 29095) by debbugs.gnu.org; 1 Nov 2017 01:31:19 +0000 Received: from localhost ([127.0.0.1]:44805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9hsF-00053z-Hg for submit@debbugs.gnu.org; Tue, 31 Oct 2017 21:31:19 -0400 Received: from mail-io0-f182.google.com ([209.85.223.182]:48615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9hsD-00053h-Vi; Tue, 31 Oct 2017 21:31:18 -0400 Received: by mail-io0-f182.google.com with SMTP id d66so2060015ioe.5; Tue, 31 Oct 2017 18:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=f4c1ZdsD4ZW+5Ivq6FsnKy7Nh3Z/87CFnQLeh6zPDeI=; b=M20DqAnNGedjcpfq+X3+N7ED2GCdFH9MTZZUfL1z5NJsABvESw3v2w6P6GbRLaOdal /mrMqdTX6PsGODyH20sbHAkJqeZRAbjaM3xK3Iph+67XHCjDyPB+c9ORfEf+d8q+kEk6 pl+Q8+BeVpLoR8/D8S5BrUIqrEWQCTXLezL3Ig4uIJFGw/VM2GhKo0fE4G8KYQJji/QL kr3r1msk+0mbFzmwzD1gf882iQ+Im6Kf0Ak7UeoXgvp2xJdkEB0LhZg+mYCwc251uMrd 6/nZ2hofwodw63ajF8ZUcrQnEstQJMEJeHgrcxgjyhWUzpUT1xDIDYCE0uHXb+lhCcEq f+Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=f4c1ZdsD4ZW+5Ivq6FsnKy7Nh3Z/87CFnQLeh6zPDeI=; b=Mgp6cdpAY1RK6TVIgmSW7BJMaIEyJSgLbrRmhGBONrYaqVxib9DM5eR/Yogm42Vm5n WPI73rJmUsBCvV2eTHU0LLbrB59mx0a85XbYrsOCx8Duwwj28SD2aeh3xvN2aDjBODe8 hqxi4wxtFuEs1NVxXkYehs/JgOYa9Q5aZyFY+wgjCaAx7nBU0Sl1M3zjkf4/qHnAGPO1 ZZVj/xW6QllOU5E2w1ntZh7xpbyD7ya4umvHp2HdTwNQD2cPqNec5qltiVpW10k+KeFZ Tb0o1nYln5i5fTzsunsHo4gDGzR06ioGd75UhjdhnGG9EpOXG6IS7JwdBAMlCjccggUU uJKQ== X-Gm-Message-State: AMCzsaVlTQ/cZM3LTzbeu+xe/oJHN9BgCfocoR5mwgC450B6/QgVpdgl 6jrOvuHuEPeSTjr9lrvp65KzGQ== X-Google-Smtp-Source: ABhQp+QWs+Eb1aB8DaKkAU7ljHVjyPkM1NtmE5HTbeGUoeJbIlX/lVNrBfyZd2cgkEyfv0god8/WYQ== X-Received: by 10.36.19.81 with SMTP id 78mr5677139itz.143.1509499871821; Tue, 31 Oct 2017 18:31:11 -0700 (PDT) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id s16sm1569258itb.15.2017.10.31.18.31.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 31 Oct 2017 18:31:10 -0700 (PDT) From: Noam Postavsky References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> Date: Tue, 31 Oct 2017 21:31:09 -0400 In-Reply-To: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> (Alexander Shukaev's message of "Wed, 1 Nov 2017 01:44:50 +0100") Message-ID: <87h8ueaioy.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) tags 29095 + moreinfo quit Alexander Shukaev writes: > Hi, > > Decided to try pretest of 26.0.90 and immediately discovered that it > is slower than, for example, > 'e7f65187580342171dd9ad32e570c50c96badb13' which I used before. In > particular, thanks to a couple of hours of bisecting, I found that the > '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs > configuration loading time from 9 s to 60 s, which is unacceptable. I know what you mean by "which is unacceptable", but somehow on first reading it strikes me as rather bossy and entitled. > I have no idea how this made it's way to the 'master' branch. This sentence kind of suggests you think that the 'master' branch is supposed to be the most stable, but it's rather emacs-26 (being the release branch) which is intended to be more stable. Note that e7f6518758 which you said is okay, is contained in both emacs-26 and master. > Furthermore, other operations like navigation across windows or > performing an incremental search are also noticeably slower, i.e. they > stutter annoyingly, and from what I see is a result of extensive GC > spam which did not occur in previous versions. Looks like something > core has really been changed and potentially broken. This needs > investigation; let me know what can I do for you guys from my side. > Thanks. I see two possible directions to investigate: 1. You bisect farther along the emacs-26 branch, as a merge commit collects a whole bunch of changes, and so doesn't really narrow things down at all. 2. You bisect and/or profile your Emacs configuration to see what part is taking so long. Ideally post something that can reproduce the slowness starting from 'emacs -Q'. Currently, your report pretty much just says "*something* is slow", which nobody can really do anything with. From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2017 03:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Alexander Shukaev Cc: 29095@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.150950788514066 (code B ref 29095); Wed, 01 Nov 2017 03:45:01 +0000 Received: (at 29095) by debbugs.gnu.org; 1 Nov 2017 03:44:45 +0000 Received: from localhost ([127.0.0.1]:44864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9jxL-0003en-TR for submit@debbugs.gnu.org; Tue, 31 Oct 2017 23:44:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9jxK-0003eb-Ex for 29095@debbugs.gnu.org; Tue, 31 Oct 2017 23:44:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9jxC-0001fZ-2O for 29095@debbugs.gnu.org; Tue, 31 Oct 2017 23:44:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9jxB-0001fU-VS; Tue, 31 Oct 2017 23:44:34 -0400 Received: from [176.228.60.248] (port=1999 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1e9jxB-0007Er-2M; Tue, 31 Oct 2017 23:44:33 -0400 Date: Wed, 01 Nov 2017 05:44:22 +0200 Message-Id: <83h8ueslwp.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> (message from Alexander Shukaev on Wed, 1 Nov 2017 01:44:50 +0100) References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Alexander Shukaev > Date: Wed, 1 Nov 2017 01:44:50 +0100 > > Decided to try pretest of 26.0.90 and immediately discovered that it is > slower than, for example, 'e7f65187580342171dd9ad32e570c50c96badb13' > which I used before. In particular, thanks to a couple of hours of > bisecting, I found that the '20a09de953f437109a098fa8c4d380663d921481' > merge increased my Emacs configuration loading time from 9 s to 60 s, By "Emacs configuration loading time" you mean the time it takes Emacs to start up when you type "emacs" at the shell prompt? Or do you mean something else? > which is unacceptable. I have no idea how this made it's way to the > 'master' branch. Furthermore, other operations like navigation across > windows or performing an incremental search are also noticeably slower, > i.e. they stutter annoyingly Is your build optimized or unoptimized? If the latter, perhaps your previous build was optimized? The difference between them could be a factor of 2.5 in speed. > and from what I see is a result of extensive GC spam which did not > occur in previous versions. What do you mean by "extensive GC spam"? Also, in what major mode(s) and what kind of files do you see this performance degradation? Thanks. From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Alexander Shukaev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2017 23:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Noam Postavsky , Eli Zaretskii Cc: 29095@debbugs.gnu.org Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.150958017317941 (code B ref 29095); Wed, 01 Nov 2017 23:50:02 +0000 Received: (at 29095) by debbugs.gnu.org; 1 Nov 2017 23:49:33 +0000 Received: from localhost ([127.0.0.1]:46603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eA2lJ-0004fI-GY for submit@debbugs.gnu.org; Wed, 01 Nov 2017 19:49:33 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:57680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eA2lI-0004fA-3e for 29095@debbugs.gnu.org; Wed, 01 Nov 2017 19:49:32 -0400 X-Originating-IP: 88.68.190.226 Received: from [192.168.2.109] (dslb-088-068-190-226.088.068.pools.vodafone-ip.de [88.68.190.226]) (Authenticated sender: forum@alexander.shukaev.name) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 6579840492; Thu, 2 Nov 2017 00:49:28 +0100 (CET) References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> From: Alexander Shukaev Message-ID: Date: Thu, 2 Nov 2017 00:49:28 +0100 MIME-Version: 1.0 In-Reply-To: <87h8ueaioy.fsf@users.sourceforge.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 11/01/2017 02:31 AM, Noam Postavsky wrote: > tags 29095 + moreinfo > quit > > Alexander Shukaev writes: > >> Hi, >> >> Decided to try pretest of 26.0.90 and immediately discovered that it >> is slower than, for example, >> 'e7f65187580342171dd9ad32e570c50c96badb13' which I used before. In >> particular, thanks to a couple of hours of bisecting, I found that the >> '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs >> configuration loading time from 9 s to 60 s, which is unacceptable. > > I know what you mean by "which is unacceptable", but somehow on first > reading it strikes me as rather bossy and entitled. Apologies, didn't want it to sound like that. Was truly frustrated by the experience. The problem was also that until the very last moment I refused to believe that I would really hit something like this on a "pretest" tag from the 'master' branch. I did OS upgrade recently as well, so I first started to profile my SSD RAID for possible performance degradation (as Emacs reads lots of file at startup) and look for any issues I could have introduced in the custom Linux kernel. I rolled back Emacs only as the very last resort and to my (unpleasant) surprise that was the culprit. >> I have no idea how this made it's way to the 'master' branch. > > This sentence kind of suggests you think that the 'master' branch is > supposed to be the most stable, but it's rather emacs-26 (being the > release branch) which is intended to be more stable. Note that > e7f6518758 which you said is okay, is contained in both emacs-26 and > master. As my original findings (namely merge commit from the 'emacs-26' branch) demonstrated, there is no stable branch at the moment as the faulty commit is now present in both. In fact, the 'emacs-26' was merged to master (and not vice versa), so it's the issue that came from what you call a "stable" branch. This is another surprise for me. >> Furthermore, other operations like navigation across windows or >> performing an incremental search are also noticeably slower, i.e. they >> stutter annoyingly, and from what I see is a result of extensive GC >> spam which did not occur in previous versions. Looks like something >> core has really been changed and potentially broken. This needs >> investigation; let me know what can I do for you guys from my side. >> Thanks. > > I see two possible directions to investigate: > > 1. You bisect farther along the emacs-26 branch, as a merge commit > collects a whole bunch of changes, and so doesn't really narrow things > down at all. And that's what I just finished doing, voilà: e1f6e3127a292e6ba66d27c49ddda4fe949569f5 Author: Noam Postavsky AuthorDate: Wed Aug 30 23:12:22 2017 -0400 Commit: Noam Postavsky CommitDate: Fri Sep 29 18:40:06 2017 -0400 And yes, of course, as soon as I found this by spending a couple of hours more doing bisecting, I did immediately set `x-wait-for-event-timeout' to nil and the startup problem was gone. However, I'm still gravely concerned that such defaults (100 ms GUI delays) suddenly get added (whatever the reason for this new option was) and affect both branches. Now, that was only the first part. I'm still going to continue bisecting further why there are new obvious issues with garbage collecting (as those seem to be somewhere deeper in the 'emacs-26' branch). For instance, while I was doing bisecting for the above finding, I kept rebuilding the Emacs package from scratch in a clean environment and I did so using `compilation-mode'. As the output from the build kept arriving to the *compilation* buffer, I kept getting "Garbage collecting...done" spam (at random times), stuttering the output coming into *compilation* buffer. You don't have to explain to me here anything about GC, I am well aware of all of these issues. The point is that such frequent GC spam and stuttering of output did not happen before and I didn't change GC settings. Now, this is not even the most irritating about this, it's rather that frequently it happens so that "Garbage collecting...done" would just hang out there and the build output would stop completely, in fact, the whole Emacs is blocked waiting for something to happen from GC but either that GC either hangs itself or it takes too long that I lose my patience. What I had to do in such cases, is simply spam just so that Emacs aborts those faulty GC attempts, unblocks, and I can finally see my build output being aggressively flushed into the *compilation* buffer (as the build is in reality already much further away from the point where the output stopped). Regards, Alexander From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2017 00:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Alexander Shukaev Cc: 29095@debbugs.gnu.org, Eli Zaretskii Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.150958208420934 (code B ref 29095); Thu, 02 Nov 2017 00:22:01 +0000 Received: (at 29095) by debbugs.gnu.org; 2 Nov 2017 00:21:24 +0000 Received: from localhost ([127.0.0.1]:46615 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eA3G8-0005Ra-3B for submit@debbugs.gnu.org; Wed, 01 Nov 2017 20:21:24 -0400 Received: from mail-io0-f181.google.com ([209.85.223.181]:49535) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eA3G5-0005RL-SN for 29095@debbugs.gnu.org; Wed, 01 Nov 2017 20:21:22 -0400 Received: by mail-io0-f181.google.com with SMTP id n137so10003358iod.6 for <29095@debbugs.gnu.org>; Wed, 01 Nov 2017 17:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=B1bD3m8cX142SJX1jmQm5u6yzMAgvHRPETyVf1fTRz4=; b=FQ+Y19OqE1TyU8oijXpLzdzn+rOJo0/wt4eLIQBUtABCUKXtSXixjydTRSL1C4xwJP BdWFG89aiyQsadHUSU7qswVvM21pajtTjOdwqtaXX10PdnhcFVD/fZgeCY4SEkWPb5xd ci1tLWWJoqfhyEy6jn1TCZR3Kh5lTpp0XoXg+zkXMjCI5+VKY1QbP2j9Kd6zfCFYg+m4 Ta1dyhTHueLBn1Dhnnxvma2SPbmblYW6iK9pIk2iCD+BWy2BAah+DTT/fqrTNCzy/rYb KpMxlKIdGCYYCgJHqA3T6HyUHV5spTTdJrCctHgUc7uKQ+zJF35qLysZPIztc8NXYvDA RfcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding; bh=B1bD3m8cX142SJX1jmQm5u6yzMAgvHRPETyVf1fTRz4=; b=KzYXLqAYQ5TqCWpxNacv7JKc46/y8vlouQ9Sem155UTzW3ASpwBawkVPxhhumyYAYx zbEM1B1TKkbd3CGi88gD6hu/k8P9lMxK6kltmJ+h4MeSZqZpAVDP2jWbh7qVcFpMEgAK IQeb1NnQbei/8rYbVTKGHPMK91lE33jKuIoganjrITEQbX62Dkhjo7SxFu8cR2w4vGJs ReDbRp828dDBpGzV3mUi4bBLhtgXP3BIYTG7iqe2OdbQ9Nt24cgRIAIVqEmWcRKGQ/f5 u7NR+MjOuhJoQIKO19XFf1YQqe/qVT00l889q7LW3xqb+xU57MzvVm+CitspvI29Bqx/ PHeg== X-Gm-Message-State: AMCzsaVE0kbNxt7jugJ/BVYLhDlEvTFzHzOGdoYvdOPv2ZXkus7omfYl H2+J3caSk2FUZn2OfeQTuwc7Zg== X-Google-Smtp-Source: ABhQp+Tu+dgGhcS26G9iajKi9eipI6gAfOAIhNMENCNY8+FyEX33iwPuzP3Cum6jPRrPUZmFJhIpRA== X-Received: by 10.36.95.2 with SMTP id r2mr190232itb.25.1509582075723; Wed, 01 Nov 2017 17:21:15 -0700 (PDT) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id t3sm816506ioa.3.2017.11.01.17.21.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 01 Nov 2017 17:21:14 -0700 (PDT) From: Noam Postavsky References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> Date: Wed, 01 Nov 2017 20:21:13 -0400 In-Reply-To: (Alexander Shukaev's message of "Thu, 2 Nov 2017 00:49:28 +0100") Message-ID: <87zi858r9i.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) Alexander Shukaev writes: >> I know what you mean by "which is unacceptable", but somehow on first >> reading it strikes me as rather bossy and entitled. > > Apologies, didn't want it to sound like that. Indeed, I didn't really think so. But I've been thinking a lot about how to avoid threads which devolve into bitter sniping (which is more common than I'd like in emacs-devel/bugs), and I think calling such things out at the beginning could help avoid misunderstandings. > As my original findings (namely merge commit from the 'emacs-26' > branch) demonstrated, there is no stable branch at the moment as the > faulty commit is now present in both. In fact, the 'emacs-26' was > merged to master (and not vice versa), so it's the issue that came > from what you call a "stable" branch. This is another surprise for > me. In this context, "stable" just means no features are getting added. Ideally no bugs either, but sometimes bug fixes end up adding bugs too. > And that's what I just finished doing, voil=C3=A0: > > e1f6e3127a292e6ba66d27c49ddda4fe949569f5 > Author: Noam Postavsky > AuthorDate: Wed Aug 30 23:12:22 2017 -0400 Hah! It was me ;) > And yes, of course, as soon as I found this by spending a couple of > hours more doing bisecting, I did immediately set > `x-wait-for-event-timeout' to nil and the startup problem was > gone. However, I'm still gravely concerned that such defaults (100 ms > GUI delays) suddenly get added (whatever the reason for this new > option was) and affect both branches. Versions 25.3 and lower all had this wait, and removing it cause some problems for other users (see Bug#25521 and Bug#25511). Therefore it was restored in emacs-26 (and (almost) everything in emacs-26 goes to master) with the option to remove it. In fact, the wait used to be unbounded, so a timeout is something of a compromise. What confuses me though, is how a 100ms delay is adding ~50s to your starup time?! Or are you just creating 500 frames on startup? > As the output from the build kept arriving to the *compilation* > buffer, I kept getting "Garbage collecting...done" spam (at random > times), stuttering the output coming into *compilation* buffer. You > don't have to explain to me here anything about GC, I am well aware of > all of these issues. Just to clarify, you have garbage-collection-messages set to non-nil on purpose? From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Alexander Shukaev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Nov 2017 23:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Noam Postavsky Cc: 29095@debbugs.gnu.org, Eli Zaretskii Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.150983809910002 (code B ref 29095); Sat, 04 Nov 2017 23:29:01 +0000 Received: (at 29095) by debbugs.gnu.org; 4 Nov 2017 23:28:19 +0000 Received: from localhost ([127.0.0.1]:51042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eB7rP-0002bG-Hj for submit@debbugs.gnu.org; Sat, 04 Nov 2017 19:28:19 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:39613) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eB7rN-0002b7-Ut for 29095@debbugs.gnu.org; Sat, 04 Nov 2017 19:28:18 -0400 X-Originating-IP: 88.68.190.226 Received: from [192.168.2.109] (dslb-088-068-190-226.088.068.pools.vodafone-ip.de [88.68.190.226]) (Authenticated sender: forum@alexander.shukaev.name) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id A2A8141C07F; Sun, 5 Nov 2017 00:28:15 +0100 (CET) References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> From: Alexander Shukaev Message-ID: Date: Sun, 5 Nov 2017 00:28:15 +0100 MIME-Version: 1.0 In-Reply-To: <87zi858r9i.fsf@users.sourceforge.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.5 (---) > What confuses me though, is how a 100ms delay is adding ~50s to your > starup time?! Or are you just creating 500 frames on startup? Hah, of course not. So I took some additional time to investigate where this comes from and in turned out to be very simple: (setq-default minibuffer-auto-raise t) causes this. I think this needs to be addressed. Either by documenting this side effect or finding a better solution. >> As the output from the build kept arriving to the *compilation* >> buffer, I kept getting "Garbage collecting...done" spam (at random >> times), stuttering the output coming into *compilation* buffer. You >> don't have to explain to me here anything about GC, I am well aware of >> all of these issues. > > Just to clarify, you have garbage-collection-messages set to non-nil on > purpose? On purpose. I want to know why Emacs stutters, so I monitor this in order to come up with better GC parameters for my workflows. Anyway, I figured out why this GC issue was happening. It's a bug with `magit-filenotify' package, which I've already reported and found workaround for. So apart from my concerns about `minibuffer-auto-raise' and `x-wait-for-event-timeout', looks good so far. Regards, Alexander From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Nov 2017 23:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Alexander Shukaev Cc: 29095@debbugs.gnu.org, Eli Zaretskii Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.150983963719514 (code B ref 29095); Sat, 04 Nov 2017 23:54:02 +0000 Received: (at 29095) by debbugs.gnu.org; 4 Nov 2017 23:53:57 +0000 Received: from localhost ([127.0.0.1]:51059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eB8GD-00054g-5b for submit@debbugs.gnu.org; Sat, 04 Nov 2017 19:53:57 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:53329) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eB8GA-00054O-V5 for 29095@debbugs.gnu.org; Sat, 04 Nov 2017 19:53:55 -0400 Received: by mail-io0-f172.google.com with SMTP id 189so12179099iow.10 for <29095@debbugs.gnu.org>; Sat, 04 Nov 2017 16:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=l52bzoWoyM9tLCkjSTNZVrE40LC1xftZK+Yl5WlHA+o=; b=hjMQ7PgQ5NhH64XIKg8HLHgYEB5zlMnw8lixNKpiZtieA8uoreqV1PJ3+FWvalWQKy OEGcSqi/DN3ZbbuKSnaqYb7Vbrl4gvOVhpH5E4o4r+j7NVfbsWzcyhz1B455jJX9EeU0 NEWQVG1q2FE3UokNmo61lZCE1vIhgwtM+/7whNibMLRUhQkyO3QSih7wyvJFg+2O83uJ M9DIy4Tz2DEa5EK1iLA/mRMyq8lPvG+1++42Hqkzsik0GOLrkPhlhNmZJNWLCbuN2PjB bM/YP7f5n2a2EP8WQ1pnNl3MC8XOZgAIE0dE13UziRIbye7lUMaRotn9rxMJG10YmXwl IskA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=l52bzoWoyM9tLCkjSTNZVrE40LC1xftZK+Yl5WlHA+o=; b=KwIKAgeGAd88yYQNKy8ZUSmvXqNo/PWmKHGjYnBAzV7ar06QFL2K+IvCm4aydwdRNC 3mijlkEFoChvHU4f+hw92cEgrwxBhzci41EXV0QRnFv6j+kQUvAVooGyJG4WJjb523Uv AWDlGx7l7hOJjuURl8rCn5HGbv3b1cvoXg8toY13pO2tUc4wqp10+Qbr4yvC4y65vMrm 3nKPlwRSFEyyAOYrrgUqV/TQhxpTmC/eQ61kOp10WvBCcq1AOOg4TXiw13h7RREEsgMQ HuAWfFIC5LDrDIQb1VZkMWB74x2wKZc3mktNqQoOwCGH4duwHKGuhbVyaLHA2PUBQx5S wN8A== X-Gm-Message-State: AJaThX6zRE7lP+Q/7Buje3WI4eE5Ztvp0TnkFQPjMzruKeSFFzztIObb RxxeJ4zhtFUgAH+ujt8J8M0= X-Google-Smtp-Source: ABhQp+Sx01RW5WAkrzQnYd+JSL8Bf9f5YmOgTDgJjU9oufevdcR7L60ZofKhd2xZIFHcg/D8uGjtng== X-Received: by 10.107.12.164 with SMTP id 36mr14404112iom.191.1509839629335; Sat, 04 Nov 2017 16:53:49 -0700 (PDT) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id 79sm2768835itu.7.2017.11.04.16.53.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 04 Nov 2017 16:53:48 -0700 (PDT) From: Noam Postavsky References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> Date: Sat, 04 Nov 2017 19:53:46 -0400 In-Reply-To: (Alexander Shukaev's message of "Sun, 5 Nov 2017 00:28:15 +0100") Message-ID: <87y3nl7g8l.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) Alexander Shukaev writes: >> What confuses me though, is how a 100ms delay is adding ~50s to your >> starup time?! Or are you just creating 500 frames on startup? > > Hah, of course not. So I took some additional time to investigate > where this comes from and in turned out to be very simple: > > (setq-default minibuffer-auto-raise t) > > causes this. I think this needs to be addressed. Either by > documenting this side effect or finding a better solution. Ah, so if I understand correctly, because of the minibuffer-auto-raise setting, every time a message is printed Emacs tries to make the frame visible, and because of x-wait-for-event-timeout, it waits for 100ms each time. So if you get around ~500 messages during startup, it would take about 50 seconds, thus explaining the increase you observed? Perhaps the thing to do is simply to disable x-wait-for-event-timeout if we end up hitting the timeout. Under most window managers the frame becomes visible much faster than 100ms anyway, as far as I know. > I figured out why this GC issue was happening. It's a bug with > `magit-filenotify' package, which I've already reported and found > workaround for. So apart from my concerns about > `minibuffer-auto-raise' and `x-wait-for-event-timeout', looks good so > far. Ah yes, I saw that. It looks like it's not actually a GC issue as such, but an (asynchronous) infinite loop that generates a lot of garbage (and hence work for the GC). https://github.com/ruediger/magit-filenotify/issues/20 From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Alexander Shukaev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Nov 2017 23:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Noam Postavsky Cc: 29095@debbugs.gnu.org, Eli Zaretskii Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.150983993519932 (code B ref 29095); Sat, 04 Nov 2017 23:59:01 +0000 Received: (at 29095) by debbugs.gnu.org; 4 Nov 2017 23:58:55 +0000 Received: from localhost ([127.0.0.1]:51065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eB8L0-0005BO-Ud for submit@debbugs.gnu.org; Sat, 04 Nov 2017 19:58:55 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:54978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eB8Kz-0005BG-Bi for 29095@debbugs.gnu.org; Sat, 04 Nov 2017 19:58:53 -0400 X-Originating-IP: 88.68.190.226 Received: from [192.168.2.109] (dslb-088-068-190-226.088.068.pools.vodafone-ip.de [88.68.190.226]) (Authenticated sender: forum@alexander.shukaev.name) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 18350FB87E; Sun, 5 Nov 2017 00:58:50 +0100 (CET) References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> From: Alexander Shukaev Message-ID: Date: Sun, 5 Nov 2017 00:58:49 +0100 MIME-Version: 1.0 In-Reply-To: <87y3nl7g8l.fsf@users.sourceforge.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) On 11/05/2017 12:53 AM, Noam Postavsky wrote: > Alexander Shukaev writes: > >>> What confuses me though, is how a 100ms delay is adding ~50s to your >>> starup time?! Or are you just creating 500 frames on startup? >> >> Hah, of course not. So I took some additional time to investigate >> where this comes from and in turned out to be very simple: >> >> (setq-default minibuffer-auto-raise t) >> >> causes this. I think this needs to be addressed. Either by >> documenting this side effect or finding a better solution. > > Ah, so if I understand correctly, because of the minibuffer-auto-raise > setting, every time a message is printed Emacs tries to make the frame > visible, and because of x-wait-for-event-timeout, it waits for 100ms > each time. So if you get around ~500 messages during startup, it would > take about 50 seconds, thus explaining the increase you observed? > > Perhaps the thing to do is simply to disable x-wait-for-event-timeout if > we end up hitting the timeout. Under most window managers the frame > becomes visible much faster than 100ms anyway, as far as I know. Do you mean to set it to nil as the timeout is hit for the first time? >> I figured out why this GC issue was happening. It's a bug with >> `magit-filenotify' package, which I've already reported and found >> workaround for. So apart from my concerns about >> `minibuffer-auto-raise' and `x-wait-for-event-timeout', looks good so >> far. > > Ah yes, I saw that. It looks like it's not actually a GC issue as such, > but an (asynchronous) infinite loop that generates a lot of garbage (and > hence work for the GC). > > https://github.com/ruediger/magit-filenotify/issues/20 Indeed, thanks for rephrasing it. From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Nov 2017 10:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Noam Postavsky , Alexander Shukaev Cc: 29095@debbugs.gnu.org Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.150987922613585 (code B ref 29095); Sun, 05 Nov 2017 10:54:01 +0000 Received: (at 29095) by debbugs.gnu.org; 5 Nov 2017 10:53:46 +0000 Received: from localhost ([127.0.0.1]:51230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBIYk-0003X2-8i for submit@debbugs.gnu.org; Sun, 05 Nov 2017 05:53:46 -0500 Received: from mout.gmx.net ([212.227.15.15]:65408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBIYi-0003Wp-Al for 29095@debbugs.gnu.org; Sun, 05 Nov 2017 05:53:45 -0500 Received: from [192.168.1.100] ([46.125.249.78]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MRWzQ-1diaY52sJ6-00SfnD; Sun, 05 Nov 2017 11:53:29 +0100 Message-ID: <59FEEDA4.4040602@gmx.at> Date: Sun, 05 Nov 2017 11:53:24 +0100 From: martin rudalics MIME-Version: 1.0 References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> In-Reply-To: <87y3nl7g8l.fsf@users.sourceforge.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rWLW0voannDFs9czHcwhvz1jFluLY0i5TryIYp8EkLTriSsQ1zX nZYcZTG+Z/Uu1fp+Ufs1omvH8L54wE6j7Z+1DPdKMJ/mhYrDqA/tAERgOkwewm4ffZ131oL IETfYOsxXOcG9zgJ64bUYFK6QxplgpqF3hLOHcRdPeIiGSANOXG9K6V0/G0TjgapFgYkeiu vmLquxeRIjQ6ELcOkxnpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ayTrvXl/VUY=:3mPAhXrWZNyb3oo1mkw+vM LBTP4gBinTegTcjAv0kJ9ffh20qgquGr/4tU2TWJqj3SnpJi+40opPHNZEtzTQ1F9Rs/XRJ6M QhdGgwHkBdEvtEPtJpUqg5aHyYa9Y6m1iPsYiAhYzmCXmu2/6fYQhmXoVzOkleo8grc3i47qi NmlkEDIdZwPM8ly+0oUh+qHHwN5oKhj9OyaC34PffedwlwzAUStMfuUO3yrflYwLkJdgSvnB9 JItyOezqw4a0e10/jSh+IM5qfRXlB9m6RwTKbYjOsS9xIWUrShyxXdFv/zK+HJl16Bqb/wIBc lKjFj5S+6LEOXAskjs2tJ9w+IN+PMhyGPGuKeOI0KcTa3LFCS0RadCeJkEAeQqMYZxtc6vnvr /r90A2U4MVrxN6OPUiuPTSnH8sclaDUDQMaGvjYecz7HL9o0RBXYAkQimFUVakWZ6YFeKSWQI oB/5jHC2+ZIDkFtt3ORK3Iwq4rkG+DHZMDLlgqGqWduLPWf6H8LPULdoI/yw9TQZ1Kyed3LpO 5ruS5od9XJnE/xxBJykS8JixOir+3Tw2LAQ1+acSE4VQ2+gEVyw248LGgqzkmTxtHfvyzFK+E yl/uLJNpNnxi5hmzPcJnpXQLD/PX+mduTdjCPSXulFUXbC6HRhHVp3QTGkBUGgJXmTmPeF+7g MFP8pMiB3hDCGtXASwOZfcTV8kqa3B70rbUcohM9ZCB6ZBAG4j40dZrkrn04Bif4HNAYrQJY2 Rdoh52ygRom9mKOzCja2WE4+b8y5e5s34rTxa3B++psdo9G+AAOkcTlrhHo/0iKu9N1P2wpyP ecUVoMwpcSPf2GDhbuJyYpZOYhoC533KsCA/1AZGRKRHoPHs5qVcqLpiP7vNrhFkqDmuA4U X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > Perhaps the thing to do is simply to disable x-wait-for-event-timeout if > we end up hitting the timeout. Under most window managers the frame > becomes visible much faster than 100ms anyway, as far as I know. If and when we do that, we should also warn and inform the user. And we probably should collect information about those window managers that are not able to inform us in due time that the frame has become visible. And maybe we're also still missing one or the other case where we could set the visibility of the frame. Alexander, can you try using the debugger to see if Emacs receives any events that OT1H do not call SET_FRAME_VISIBLE (f, 1) but OTOH still qualify as ones that make sense only if the frame is visible? I know it's a vague question but this is primarily a timing issue and as such rather subtle. martin From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2017 09:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: martin rudalics Cc: 29095@debbugs.gnu.org, Alexander Shukaev Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.15100458244170 (code B ref 29095); Tue, 07 Nov 2017 09:11:01 +0000 Received: (at 29095) by debbugs.gnu.org; 7 Nov 2017 09:10:24 +0000 Received: from localhost ([127.0.0.1]:55161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBzto-00015C-7w for submit@debbugs.gnu.org; Tue, 07 Nov 2017 04:10:24 -0500 Received: from mail-io0-f172.google.com ([209.85.223.172]:48835) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBztm-00014y-Dn for 29095@debbugs.gnu.org; Tue, 07 Nov 2017 04:10:22 -0500 Received: by mail-io0-f172.google.com with SMTP id d66so1371456ioe.5 for <29095@debbugs.gnu.org>; Tue, 07 Nov 2017 01:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=VDGIH6m5xjEItd2Irvm2AfIFphRuxkF1/Se2hEIH8OM=; b=nD6zrnkXuFn9RCz0uTxK/3jlg2EC9Se7YFL7i9ToJTW5FO/rEcIbcOiaoXfVklZxEI N+SOifzaNcBdCCF0KbhTF803VsiOfCFLM52lkMWLRpZKvHsnH0bQLfSV8uM0sPDxLH4U iB2H1aOu73Ecn9D3Lth8lSBwgJq4hR52+04vyOYhgHkHVbyjt/9bpdejl3Em+u/veHbY 6B3bCUwqmFBxfpp85irVuDU3KWzeRRuAH03UXmFhZ8Qkrrzd6KOSPc2gd1PiAU4jQTRW 2h0op77YSfMVAHl2I4e7epaPt140V8PSWrefX63FRbkuAyyfY08TURRAkFXxCGBjfAeA tBNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=VDGIH6m5xjEItd2Irvm2AfIFphRuxkF1/Se2hEIH8OM=; b=OZChKwoUEOylL5lj01E7cjlamGEILCpkHYHzNItyO0u9mH0GmszT9C+10pWvhx1L3o Rgn3btyI/l5dhgSBYF07aGSS5SKxmxRt9S4vf9TjrEDkVUPAsxQHEECBjrrLKpUtBUnv /mntzlDHYGE8N9P6LaV1Y3qifPthDxwIUoG6mkD+ENSjPOB7/YxJ/BbN3x5uMbXBgMiO Ew1qZKrIyzMdbxiJWhpz1Cqoh6JnOmV8tW8S19EdiQKtR2y3tPefAKiDVzjef82GHr3b cDH2B+wZ4bzWSP04k6kTrun0YmDQKyVIXliRuQiVRc4JFPMHZQV9e5gQ1mu077E7G6Xi YHMg== X-Gm-Message-State: AJaThX4mluLT9lflk194+fa58mavRSp/CWcq/R9pFZ5ELoB4FwHyDJ/J oQU/FhoeCiXRwaIRgg1Kf2lK1Q== X-Google-Smtp-Source: ABhQp+SlITkwuZShRu6CXBmdkBHAiwnp80/LLA5Du9YPpCkxISa3fga8126KEkEIeC0rk9Gt5Y9dxQ== X-Received: by 10.107.200.207 with SMTP id y198mr2384102iof.157.1510045816408; Tue, 07 Nov 2017 01:10:16 -0800 (PST) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id r16sm423702ioi.61.2017.11.07.01.10.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 07 Nov 2017 01:10:15 -0800 (PST) From: Noam Postavsky References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> Date: Tue, 07 Nov 2017 04:10:14 -0500 In-Reply-To: <59FEEDA4.4040602@gmx.at> (martin rudalics's message of "Sun, 05 Nov 2017 11:53:24 +0100") Message-ID: <87d14u5ua1.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --=-=-= Content-Type: text/plain martin rudalics writes: >> Perhaps the thing to do is simply to disable x-wait-for-event-timeout if >> we end up hitting the timeout. Under most window managers the frame >> becomes visible much faster than 100ms anyway, as far as I know. > > If and when we do that, we should also warn and inform the user. And we > probably should collect information about those window managers that are > not able to inform us in due time that the frame has become visible. Not sure what Alexander is using, but under i3 the problem is simply that the frame doesn't become visible until the user switches to the virtual workspace where Emacs is. So it's not that we have a visible frame which the window manager fails to inform us about in time, rather the frame just doesn't become visible in time. It occurs to me that another possibility is simply to disable the timeout when doing the auto-raise. We have the timeout due some users' configurations accidentally relying on the fact that a frame will be visible after make-frame returns, but it seems unlikely that anyone would manage to rely on the frame being visible after a call to `message' occurs. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Don-t-wait-for-X-events-when-auto-raising-frame-Bug-.patch Content-Description: patch >From 9ab2cb84378dd73bd599a8445c32e305bb342819 Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Tue, 7 Nov 2017 03:41:34 -0500 Subject: [PATCH] Don't wait for X events when auto-raising frame (Bug#29095) * src/xdisp.c (message3_nolog) (setup_echo_area_for_printing): Let-bind x-wait-for-event-timeout to nil while calling raise-frame. --- src/xdisp.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index 69b74dc629..18fd8c32b9 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -10530,7 +10530,12 @@ message3_nolog (Lisp_Object m) { set_message (m); if (minibuffer_auto_raise) - Fraise_frame (frame); + { + ptrdiff_t count = SPECPDL_INDEX (); + specbind (Qx_wait_for_event_timeout, Qnil); + Fraise_frame (frame); + unbind_to (count, Qnil); + } /* Assume we are not echoing. (If we are, echo_now will override this.) */ echo_message_buffer = Qnil; @@ -10971,7 +10976,11 @@ setup_echo_area_for_printing (bool multibyte_p) struct frame *sf = SELECTED_FRAME (); Lisp_Object mini_window; mini_window = FRAME_MINIBUF_WINDOW (sf); - Fraise_frame (WINDOW_FRAME (XWINDOW (mini_window))); + + ptrdiff_t count = SPECPDL_INDEX (); + specbind (Qx_wait_for_event_timeout, Qnil); + Fraise_frame (WINDOW_FRAME (XWINDOW (mini_window))); + unbind_to (count, Qnil); } message_log_maybe_newline (); -- 2.11.0 --=-=-=-- From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2017 12:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: martin rudalics Cc: 29095@debbugs.gnu.org, Alexander Shukaev Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.15100594431694 (code B ref 29095); Tue, 07 Nov 2017 12:58:01 +0000 Received: (at 29095) by debbugs.gnu.org; 7 Nov 2017 12:57:23 +0000 Received: from localhost ([127.0.0.1]:55294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eC3RT-0000RG-CP for submit@debbugs.gnu.org; Tue, 07 Nov 2017 07:57:23 -0500 Received: from mail-io0-f169.google.com ([209.85.223.169]:54406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eC3RR-0000R4-T9 for 29095@debbugs.gnu.org; Tue, 07 Nov 2017 07:57:22 -0500 Received: by mail-io0-f169.google.com with SMTP id e89so1985647ioi.11 for <29095@debbugs.gnu.org>; Tue, 07 Nov 2017 04:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=aXYDAfV1Q8P1AGKGqguW6e2Ex24ImOunE/f5M8UV/po=; b=b4J6A/krxZL5GGKEfWS0AyvkoK9OFq0V8ALqgAR+MLo9rJcv5Z60CH+4bl9WHkoft5 psU3BABXORK6M1DMp1wYuSYOPyIyEuiQbZKciLcggL8GFlOW7wKvZeaYjFXU6EYD6oFM 1/GabkVHMCUJ2QkixiZhgX0x8aahFY9MszjpqfCiup97RJDQGmTEsQbA8tgWbgacFhO5 n2NMWCpAwSZIvaVliYRnj2tZxijL6FJb6sbS7oJe5Cj2lJcZmESWK1sfhlMpFwzRkaUp vEfAZu9rhBsPsp6XVlgo4owYQAILlAE6ReOieQPB+jozEHgQsUTyOPtnn3fbp54ujI/f /mfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=aXYDAfV1Q8P1AGKGqguW6e2Ex24ImOunE/f5M8UV/po=; b=iIDSFKakC1Wu4b56d+duBm0V8/gAHH1wl4i9bugbWIaOcaRR9H2Oz3+rtwc2AfAfWJ R7ZRwshyu6Gx+qY2K/odXKwGQD4fBannaj8LhpulXRdWE10WNI1cjLFnbzOvxNuogKOQ Ry9WLDpAfka3rEz565mpEizZxRtRQRZ46iPZuKCLRfwcCZ34Vh/TzNv6f97mDPwLJ7ZA Ih83UGt4l0Fk3JHD48q/ZKj/eZTBLW/CtwsAwkYB68FOwiMzYGx44ZEhs0P0EKEgRw9k +VR6u4DrWzjoB9Rryh4AxSJb6NxluevKc9CxvZTU1cxUoinoio/OQpj/R3aZzm4l0NYg K7Cg== X-Gm-Message-State: AJaThX5XufBrHF78Gzv2LpC8HJ5pmyFNqPXK7V7BCMsuvoI15xghOMwi w1SOoBiyKYonZSVsLe+TNtg= X-Google-Smtp-Source: ABhQp+RKEEoR9sLchH1WwtQWds2UNQm2u+9Fskeoctj1IvSneTBiNzjXW7B9HTQUThn9T9zufrdD5A== X-Received: by 10.107.139.146 with SMTP id n140mr23824613iod.266.1510059436128; Tue, 07 Nov 2017 04:57:16 -0800 (PST) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id j71sm6505807itj.2.2017.11.07.04.57.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 07 Nov 2017 04:57:14 -0800 (PST) From: Noam Postavsky References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> Date: Tue, 07 Nov 2017 07:57:13 -0500 In-Reply-To: <87d14u5ua1.fsf@users.sourceforge.net> (Noam Postavsky's message of "Tue, 07 Nov 2017 04:10:14 -0500") Message-ID: <87a7zy5jrq.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) --=-=-= Content-Type: text/plain Noam Postavsky writes: >>>From 9ab2cb84378dd73bd599a8445c32e305bb342819 Mon Sep 17 00:00:00 2001 > From: Noam Postavsky > Date: Tue, 7 Nov 2017 03:41:34 -0500 > Subject: [PATCH] Don't wait for X events when auto-raising frame (Bug#29095) Sorry, forgot the DEFSYM. Here's a patch which compiles. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=0001-Don-t-wait-for-X-events-when-auto-raising-frame-Bug-.patch Content-Description: patch >From 37e98e2b1ecaa0e594bd5a92fbf8f55e7c918fde Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Tue, 7 Nov 2017 03:41:34 -0500 Subject: [PATCH] Don't wait for X events when auto-raising frame (Bug#29095) * src/xdisp.c (message3_nolog) (setup_echo_area_for_printing): Let-bind x-wait-for-event-timeout to nil while calling raise-frame. --- src/xdisp.c | 13 +++++++++++-- src/xterm.c | 1 + 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index 69b74dc629..18fd8c32b9 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -10530,7 +10530,12 @@ message3_nolog (Lisp_Object m) { set_message (m); if (minibuffer_auto_raise) - Fraise_frame (frame); + { + ptrdiff_t count = SPECPDL_INDEX (); + specbind (Qx_wait_for_event_timeout, Qnil); + Fraise_frame (frame); + unbind_to (count, Qnil); + } /* Assume we are not echoing. (If we are, echo_now will override this.) */ echo_message_buffer = Qnil; @@ -10971,7 +10976,11 @@ setup_echo_area_for_printing (bool multibyte_p) struct frame *sf = SELECTED_FRAME (); Lisp_Object mini_window; mini_window = FRAME_MINIBUF_WINDOW (sf); - Fraise_frame (WINDOW_FRAME (XWINDOW (mini_window))); + + ptrdiff_t count = SPECPDL_INDEX (); + specbind (Qx_wait_for_event_timeout, Qnil); + Fraise_frame (WINDOW_FRAME (XWINDOW (mini_window))); + unbind_to (count, Qnil); } message_log_maybe_newline (); diff --git a/src/xterm.c b/src/xterm.c index dbb8349452..d021546c5e 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -13325,6 +13325,7 @@ syms_of_xterm (void) so it is important to limit the wait. If set to a non-float value, there will be no wait at all. */); + DEFSYM (Qx_wait_for_event_timeout, "x-wait-for-event-timeout"); Vx_wait_for_event_timeout = make_float (0.1); DEFVAR_LISP ("x-keysym-table", Vx_keysym_table, -- 2.11.0 --=-=-=-- From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2017 07:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Noam Postavsky Cc: 29095@debbugs.gnu.org, Alexander Shukaev Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.15101252298888 (code B ref 29095); Wed, 08 Nov 2017 07:14:01 +0000 Received: (at 29095) by debbugs.gnu.org; 8 Nov 2017 07:13:49 +0000 Received: from localhost ([127.0.0.1]:57481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCKYX-0002JI-1m for submit@debbugs.gnu.org; Wed, 08 Nov 2017 02:13:49 -0500 Received: from mout.gmx.net ([212.227.17.21]:62705) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCKYV-0002J5-Mz for 29095@debbugs.gnu.org; Wed, 08 Nov 2017 02:13:48 -0500 Received: from [192.168.1.100] ([46.125.250.45]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LeiJ8-1f1J5u0m8E-00qPp1; Wed, 08 Nov 2017 08:13:32 +0100 Message-ID: <5A02AE92.6010201@gmx.at> Date: Wed, 08 Nov 2017 08:13:22 +0100 From: martin rudalics MIME-Version: 1.0 References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> In-Reply-To: <87d14u5ua1.fsf@users.sourceforge.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:vdiP2GRlEI4GHVHApjW1uN9EF2Fk9h5x/8ndyFbMlWUvtsma9K0 9OhyfHE47x6NhF1EDBifLPcFXUlBzV4WMgg0ForS9V6YW7gjLPEm/afCs7QCjyoU2GMLUIt UBSjKYiUXtTj1wlsk3Sne0LpZ/SVrlcKetSBrvR1ugmu0Afd2Zk9bSN8VxhC5fjYq0KHmxp jPgpcz9rL1egSUFYz3Tlg== X-UI-Out-Filterresults: notjunk:1;V01:K0:HnjgjS8sRfc=:yJlfaKXmDpzNc/qsxNz8kX AArtWfkxTzOm6aWAkh+dZr3ygpPnMD7q2ssfVpVSlPPIvWq93xDONkyZa2+L3lZ0zxHohIK+W WfpX5jd8v907xcRi/sZaD2M2mlw+7hSLC70tGvXijOE0NvT7AIkSSzlN0ys6VA31nQ0kKmZeg Sz6UIlxdEDUidV5J49yBTlcXlE+KbIb61Gee9x01CKowdXmZ9UY/w+SaA7Z7aQvb4LzHzmmVp 3e3cspZNAjcY4QkZm5WEVfGNzWz+jGYMjQNRG/vKatQDLlCA5SNLQSjlxsePVEZaNGjXgINTW 7VO/5MtqqxT6mXx+KDdNM5wggzd5DOPz2WmVhgWq7YGeUuD45I+BGymOQkl2+TNg19pW5KaOI YVJ/e9NBJX/S7DDcCQAT5QbQogxR/fl4WVtXWyDJQzbg4hTudeNixkP2p0w1npoqGNWXR9hMl 6TCV6ZCh3L+rv3wZQVYj/ABK92Pu/tpcHkrHG0KpNBzWCCBhxJHGXVwBiK2aahqA2U1lv8lUc 0g9bzgnMXTODT2PdNHHbCDLoMIgZTA+3603UEPYgrI0I7oig5mjQrujvXFHb2WhUZm1TVDQVa 3oWhcTaHB1aWka3TW3ylK0pebHgLwfvYF0UoaygNfWP8GgBVYFJ6OgspY7goaESaznpGNNa7w 5ffv2ecMDoAGoxIkCbT/ck+pvJ+tp33HAS/LOufp9rI++atJI88Nlgs9mbd46cMRM2NMNRsT9 pVNKUMw9KI0ShLPE7JzK3DQ4XxFzdaI0uCxFaBb4iVWLgEwDl6jINjOdtUpVs9NgCswz6kACf kcVqwj1ppbr5JIJrNYI+azo24SaWb380uYR2pFHEzIrAkC4AUDBQTnRtdMBOx+zDA9M611x X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > Not sure what Alexander is using, but under i3 the problem is simply > that the frame doesn't become visible until the user switches to the > virtual workspace where Emacs is. So it's not that we have a visible > frame which the window manager fails to inform us about in time, rather > the frame just doesn't become visible in time. But as long as a user doesn't switch to that workspace she won't observe that making a new frame is slower. So I seem to be missing something. Anyway, we probably should add to /etc/PROBLEMS lines like "If a new Emacs frame is supposed to appear on a different virtual workspace, Emacs may not be notified about the visibility of the frame until the user switches to that workspace. If this causes ... one remedy is to customize ..." And I'd still be interested in Sasha's use case. martin From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2017 07:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Noam Postavsky Cc: 29095@debbugs.gnu.org, Alexander Shukaev Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.15101252518957 (code B ref 29095); Wed, 08 Nov 2017 07:15:02 +0000 Received: (at 29095) by debbugs.gnu.org; 8 Nov 2017 07:14:11 +0000 Received: from localhost ([127.0.0.1]:57485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCKYt-0002KP-9Z for submit@debbugs.gnu.org; Wed, 08 Nov 2017 02:14:11 -0500 Received: from mout.gmx.net ([212.227.17.20]:50314) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCKYr-0002KB-F2 for 29095@debbugs.gnu.org; Wed, 08 Nov 2017 02:14:09 -0500 Received: from [192.168.1.100] ([46.125.250.45]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LvDpe-1fBGrY08aA-010JoE; Wed, 08 Nov 2017 08:13:54 +0100 Message-ID: <5A02AEA9.10403@gmx.at> Date: Wed, 08 Nov 2017 08:13:45 +0100 From: martin rudalics MIME-Version: 1.0 References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> In-Reply-To: <87d14u5ua1.fsf@users.sourceforge.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VrfkrDKslAVLBdVr7UyaZO7mN3zPpvD3RtwKn2srDLw7/DctxcT CRnlm7anDm+bd3oW22BzvCU4yOOAMuIDo5ci7fG7SyJxqNYqd6BUgIfZco/+WSOpP5Sqta6 qs48HlcWYbEv3BRhJLX/02RAsVmT85qrXk65OS5kb2AJlzy5VLtW2uLUps/AKiPsJGPVI9l xpvf9DGZvUxAjzEwCTdRQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:uBfbgrJaMb8=:7dJzt68u6LcAVqG5hZkjP6 ROjVyidNf3/Dquk7BtOqomt/mx0wG/rUVjW2QQkAlNwFelgbitA7TSS/bKjYvoh5aluRyqAdn pSU3S38yMIlKq4zcRS4Z38BVYu52CEgxBkrdCBMtbtG31rSrfMKknrqES4bZUe1K03gljA0tB aL10KwC7KPlwfwDNzDpz6PASbIT0fNRM1OR/vgu3f3E7JrXSwMIVcw9ErgXT2UTZ+PE4C71jp HMTJux+ApRiBdbreYyoih/npF4IHm08Brb9IAM6LR5DzYU3DQHp9Q6m6aH8H/VMT3b2xxwRZB t+DB0V+i7FdTxBhMVkmI8dF25nWJ8Yjf8yjinDskKu1n6TnmPO8wuAmjCJi3BemnwHp3+G1oQ XKiUxKmih7fSsbpu6/l2JYstgut8DR9w/IDntkL7mtLhxYPBLtS81bTW0UEOv+qTttJwackBM 44JpREj2ZhBba9uQBEpT+w6VuJBy+2tiZMDgt/GUYA9zNP9CRHQ/Em1JQeLZvq+z7ucYbcN1o qWrSPzB8mXzJs404ktATwdQYZRWO+dewgGzoX4keI0Kj7t5aUaYkpyjMpbg3VuN7Ls9ewRmxF ycI/0hyIoRlaZ83YS4l3EOKnprB0fTBPw+t7/nbW7vDuM7K+zQBtw/IY+Nv4ruDUdLUYjHt1d +RGxAq/s+NLjyj5i8o/nnFHnabVOu11iW3j71zC8v3XbMXxjhQ/bvspzfNkzERuGNEBFhnt8O 5t1Y/AUHegAINJaUPCy510E8S/rjk6LnhqQOthI4zRFFbtgpx5ectDnNzr40heLepwY8kWzqc xhFotG55p2YilFMwx5vsJHdBo2EHnvlq5u8ECATNEv1zATb/G1Cf717bg77tZD20LVBmFJb X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.5 (---) > It occurs to me that another possibility is simply to disable the > timeout when doing the auto-raise. We have the timeout due some users' > configurations accidentally relying on the fact that a frame will be > visible after make-frame returns, but it seems unlikely that anyone > would manage to rely on the frame being visible after a call to > `message' occurs. But missing a message from an auto-raising frame does not sound like a good idea either. That is, if the timeout is supposed to catch a problem with the Emacs/window manager interaction and to prevent Emacs from proceeding until some user decision based on something to be shown in a visible frame has been made. I wish we would have had the courage to go through with your first solution - omit such waits completely. I'm still surprised that we had so few complaints back then ... martin From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Nov 2017 13:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: martin rudalics Cc: 29095@debbugs.gnu.org, Alexander Shukaev Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.151014853528067 (code B ref 29095); Wed, 08 Nov 2017 13:43:02 +0000 Received: (at 29095) by debbugs.gnu.org; 8 Nov 2017 13:42:15 +0000 Received: from localhost ([127.0.0.1]:57734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCQcQ-0007Ic-Tq for submit@debbugs.gnu.org; Wed, 08 Nov 2017 08:42:15 -0500 Received: from mail-io0-f173.google.com ([209.85.223.173]:54977) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCQcQ-0007IO-2J for 29095@debbugs.gnu.org; Wed, 08 Nov 2017 08:42:14 -0500 Received: by mail-io0-f173.google.com with SMTP id e89so5951601ioi.11 for <29095@debbugs.gnu.org>; Wed, 08 Nov 2017 05:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=7cyzCPsjs9Ik7s0CuYmPiAkewlQJbklry5LTQTowrgU=; b=EY7qgIc5HkmHdYQuTd+xxlUbopkAUAe8aSGTwWpKWzRkW21ajPkCycWuIoZDLghkKk mRSAb50LRJPu9xwk03yi5vcPnuHxzQM+dv1TvnvKR3OxKWQikVb3952Jr6hWZv8+pgub RWuyazaBSnVvIMu0L9Cs0upPY6/mlNBLsLa/fo4hYJjnPz4zvj4WYhOXZ997RVZyLF1b 6zI9oVRDx62ahUSBIpIkpqueIYOtty/x3Wm/l00iNePfn8e4Qlq+CC1B3uBULZJ9vMTE udOOamnVZcY5tYnqtelOH9SOLWm5rIZP4luEpNo6yS0xTA2PGKKvWJDv+SlVGh7oG55N AEEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=7cyzCPsjs9Ik7s0CuYmPiAkewlQJbklry5LTQTowrgU=; b=jHWpsLeHPKAu3fGFbGWN7LWE1vFKrYr8FC11S7DMKPaTSM9LAwNOxjI8pcZo/2Wy0/ S+6n6S473xQe19k6dU4jwD/1ZVR1Nyy0ozTd2Mj+A3AOR/1YmbTcv8FsS85hrV1IIBZA AnoyIwvngL/Dq6inPrbv4k9ky2gI5MGJ0rFqK66S0GtkK/DwwNwYh7jGTCOGn81iHdMh x30YoPv0pzm+i5Xn9JEwzt1y+T6+neen9RHyLvofD5C4xu9uKRMeL1L4J4fnjrGQVcXU 074ElNa60uYndrTfUgiMxrHNxCIaWxvyG/XEpXfDrehbjb/j2H5RtfgFrwC1ZXPyyDLf R97w== X-Gm-Message-State: AJaThX5PrOedhmlGrwhvdSbxHXpVzyh5jiveAYY67gULmZXYn4a71dUz 3HwJaE77Izj4M/pvyY9jE+c= X-Google-Smtp-Source: ABhQp+Sji6QZ/2TI/LuaNx/vNCV18A/NNnGLk1qSH4SyJfzlkL4ijoKNVTUDVKH2axOx2jggEb8xcw== X-Received: by 10.107.112.12 with SMTP id l12mr740210ioc.122.1510148528369; Wed, 08 Nov 2017 05:42:08 -0800 (PST) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id 129sm2252953itx.11.2017.11.08.05.42.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Nov 2017 05:42:07 -0800 (PST) From: Noam Postavsky References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> <5A02AE92.6010201@gmx.at> Date: Wed, 08 Nov 2017 08:42:06 -0500 In-Reply-To: <5A02AE92.6010201@gmx.at> (martin rudalics's message of "Wed, 08 Nov 2017 08:13:22 +0100") Message-ID: <87vaik51ld.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) martin rudalics writes: >> Not sure what Alexander is using, but under i3 the problem is simply >> that the frame doesn't become visible until the user switches to the >> virtual workspace where Emacs is. So it's not that we have a visible >> frame which the window manager fails to inform us about in time, rather >> the frame just doesn't become visible in time. > > But as long as a user doesn't switch to that workspace she won't observe > that making a new frame is slower. So I seem to be missing something. She can observe it indirectly via lisp code. > Anyway, we probably should add to /etc/PROBLEMS lines like > > "If a new Emacs frame is supposed to appear on a different virtual > workspace, Emacs may not be notified about the visibility of the frame > until the user switches to that workspace. Hmm, not sure. This sounds to me like "Emacs may not be notified about the visibility of the frame until the frame is visible". Which doesn't seem like something which belongs in /etc/PROBLEMS. >> It occurs to me that another possibility is simply to disable the >> timeout when doing the auto-raise. We have the timeout due some users' >> configurations accidentally relying on the fact that a frame will be >> visible after make-frame returns, but it seems unlikely that anyone >> would manage to rely on the frame being visible after a call to >> `message' occurs. > > But missing a message from an auto-raising frame does not sound like a > good idea either. That is, if the timeout is supposed to catch a > problem with the Emacs/window manager interaction and to prevent Emacs > from proceeding until some user decision based on something to be > shown in a visible frame has been made. I was operating under the assumption that the timeout is for the benefit of the user's lisp code, not their interactions with the UI. Not sure the timeout would be that helpful for missing messages; under normal circumstances it's not even hit, and 100ms goes by pretty quickly for a human... > I wish we would have had the courage to go through with your first > solution - omit such waits completely. I'm still surprised that we had > so few complaints back then ... I would still like to phase it out. Maybe we could set the default to nil for Emacs 27? From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2017 07:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Noam Postavsky Cc: 29095@debbugs.gnu.org, Alexander Shukaev Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.151021255331576 (code B ref 29095); Thu, 09 Nov 2017 07:30:03 +0000 Received: (at 29095) by debbugs.gnu.org; 9 Nov 2017 07:29:13 +0000 Received: from localhost ([127.0.0.1]:59364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eChGz-0008DE-KX for submit@debbugs.gnu.org; Thu, 09 Nov 2017 02:29:13 -0500 Received: from mout.gmx.net ([212.227.15.18]:51855) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eChGy-0008Cw-JO for 29095@debbugs.gnu.org; Thu, 09 Nov 2017 02:29:13 -0500 Received: from [192.168.1.100] ([46.125.250.13]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LvVUR-1fDM423uTL-010dQS; Thu, 09 Nov 2017 08:28:58 +0100 Message-ID: <5A0403AE.6020305@gmx.at> Date: Thu, 09 Nov 2017 08:28:46 +0100 From: martin rudalics MIME-Version: 1.0 References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> <5A02AE92.6010201@gmx.at> <87vaik51ld.fsf@users.sourceforge.net> In-Reply-To: <87vaik51ld.fsf@users.sourceforge.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:2jBMNKFjUc3wg1AxwVJ/UHZ7m7RIf5dj27TGl+Lp41CyC7ALeBH Ec9KsB/zoKFbqhHjN+SNEt07pTSD1bEtHa9pWU+dJ1HUINEPIy+CRG40Ui9DDJtNt2dqwfy PH4twkS+F+VBH6P8+hQvgpmeRaL+NicVB5PScafqfg2+To5fK5wOj0N4qHM1pbUFa5PaTLB 0Vok3Gxw1kIg4ACOmt8cw== X-UI-Out-Filterresults: notjunk:1;V01:K0:enSzHgPZHuA=:8520822/2Um7l2XPI1yW9Z 2VK57BYuAcara7UB+xzQWz6vLzPq8WIHn/mjpaeoxYDaqelzCzzGTpAJootChneR2IyJxe1aM 1qtaIIb960ib6zUWvROlaISlo6z9aYvcRE6X34VDqWSSlyrLoHaajeDdfVFKwLBggmjkRiVbR JXxxTid4idwkkWoZbV2j6iT6zb+EmJhdZnNDkBzajedLmtImkOqMrQV6mqkVrRkG60X8KpNx+ DEIbjYCHDct9VtyNfm8xnVzO2R331DQU9Jfn425Sbea1Bz2mZCmrhzIuAqmSndWgW7Vvic2f/ 8ybJxC7TWs4MiKiQpoBr7+PxRYY2xMRVgM3x8fU5iUhT69DAldiV0PvAu8ouBoHKMonEs3OTD 7vuY3UcMjwrQkzsCiznhCx6bzAFRlGget+INhMPMyJdnpMFFMykkFGtJ/gZSiYRKSbJTwGLHN gEjQL/s9LBzs5rdFreYr1ucLqe7OLC/vKSIne0V0b0t5UkWdaYGE0G1QTgMPOvuf7bSTT3tkb 6JiAgYPCIZdHB5XZ8CoLO8cigyE0nhy6bmZt8MxDdTnJabTsOWaLcB04ID2SuSg+JmLsNRKjO QI/6XY2sF7joWVyqh0LLXcPZbII8AzN1y4NtNwgbr0KHcRqR6G7dJSG8i+VnHz0D0sWCNCdLR 6SKqOPoG5z4OtQahzYjClctBReZXXgb5EJr9INWVl0sKqHxj6mW0HgL7HPgCaYT8fw14PGjQy VnMQ6VF25rFJyf/AgGoBWX43LZktBv9d5vWcFOF81fVNVEUMeBQg3BMm+fp4r4n8r5wnIY8D8 VlrSdtyjrmEevYn16N1FeL0vtcvYqR3RKPuV2ruQiYwuCZlV2VZJ2y1dyIQCNxPgJLfqB1m X-Spam-Score: -0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.2 (/) >> But as long as a user doesn't switch to that workspace she won't obse= rve >> that making a new frame is slower. So I seem to be missing something.= > > She can observe it indirectly via lisp code. But Alexander said Furthermore, other operations like navigation across windows or performing an incremental search are also noticeably slower, i.e. they stutter annoyingly, and from what I see is a result of extensive GC spam which did not occur in previous versions. Looks like something so he must have had a direct, immediate experience. >> Anyway, we probably should add to /etc/PROBLEMS lines like >> >> "If a new Emacs frame is supposed to appear on a different virtual >> workspace, Emacs may not be notified about the visibility of the fram= e >> until the user switches to that workspace. > > Hmm, not sure. This sounds to me like "Emacs may not be notified abou= t > the visibility of the frame until the frame is visible". Which doesn'= t > seem like something which belongs in /etc/PROBLEMS. Apparently there are corner cases (like that of the virtual workspaces) where we cannot fulfill a contract that =E2=80=98make-frame=E2=80=99 and =E2=80=98make-frame-visible=E2=80=99 supply a visible frame at the time t= he operation terminates. So either we should not provide such a contract in the first place or mention that in some cases there are obvious problems. > I was operating under the assumption that the timeout is for the benef= it > of the user's lisp code, not their interactions with the UI. Not sure= > the timeout would be that helpful for missing messages; under normal > circumstances it's not even hit, and 100ms goes by pretty quickly for = a > human... I think that Lisp code (1) must be able to deal with the fact that any frame is currently invisible and (2) should never wait until a frame gets visible. In my experience being nice to Lisp code sooner or later fails. > I would still like to phase it out. Maybe we could set the default to= > nil for Emacs 27? I'd set the default to nil for the release. Did we have any open bugs when you added that option? martin From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2017 13:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: martin rudalics Cc: 29095@debbugs.gnu.org, Alexander Shukaev Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.15102336467333 (code B ref 29095); Thu, 09 Nov 2017 13:21:02 +0000 Received: (at 29095) by debbugs.gnu.org; 9 Nov 2017 13:20:46 +0000 Received: from localhost ([127.0.0.1]:59531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCmlC-0001uC-4L for submit@debbugs.gnu.org; Thu, 09 Nov 2017 08:20:46 -0500 Received: from mail-io0-f176.google.com ([209.85.223.176]:54095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCml9-0001tv-Cy for 29095@debbugs.gnu.org; Thu, 09 Nov 2017 08:20:44 -0500 Received: by mail-io0-f176.google.com with SMTP id 189so9779909iow.10 for <29095@debbugs.gnu.org>; Thu, 09 Nov 2017 05:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=JzDZ3qOQq9DwZDgPZ+Z9+4v1A/K7mFU/C+hZgR6Aaf0=; b=ja1UJRLU+9FKl2UJj2Oik1wReBg/drxlHo2LzGSSD+N98P6b7PuBn1K69XauEOXnkR AmpV2zDpjtBL7wZLglZBikP0v4vKEmBZg2pVV4aDJxKu2vibuX2PZLoaSLELS4shrSir itikpdYkpZDp9Znsug63MMj/Lel/5yB2Efewn9Vju4iE+CjYkK/k9xX/4odzaPgDEZxO ilfZHc8IvUq6k2Kd8SgRQagX8pRQqcBc4gYGgndp0M+LZKjIWuopWqxB2Ni755o4w2rI U21H5q+KW20AND8BG7IlSSjYuatc9q9eQsWDXwexxB4shN1jeRujQWp6TwJcy03/1WhW iaZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=JzDZ3qOQq9DwZDgPZ+Z9+4v1A/K7mFU/C+hZgR6Aaf0=; b=jIZuUNqdL/IGmdLh/nygqw2929sQSl/002lHyWe+aqkrOvp492fzo93nXW/VvKFMGy TpaodfB7wr+e6pVfbgoF/421SxTgikNnoacs643F/30XZ1mxrf+sayRcwWsGkH0Ejxoy ovmIFzS9Z3RZLVzOn5MDHFlhViwFOQZswXjC/3s/a5AO9l9l7oM063OOwP7BYXH9ao1g zSxYVPG3mDnRjW7z5cF4FAVlSTOhSulJCMvzIatehFUYvivMBhUJ/4beOyQqtxF+HSPW 2bcUmTyS6N2bqSL9tmvg3nxWLVwHEi2pWfo1CQ/7f7ph4pOSTijhJHhMVTIOm0LSF5lZ b2nw== X-Gm-Message-State: AJaThX4ZDorFWpot6gpo4XSYDSl9a9by3FHyUBTxNQm+NYeUJnag61Zz BakHN9cZ7XaPT7f2z+MlWA8= X-Google-Smtp-Source: ABhQp+RGemtDXzYduW9Uezmy47KtD0PduZnSWVL7Bg2caCz7WZUtw23v3b019d+VvrFZRgJsHyTugQ== X-Received: by 10.107.181.215 with SMTP id e206mr545965iof.98.1510233637486; Thu, 09 Nov 2017 05:20:37 -0800 (PST) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id p84sm3881575itc.3.2017.11.09.05.20.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Nov 2017 05:20:36 -0800 (PST) From: Noam Postavsky References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> <5A02AE92.6010201@gmx.at> <87vaik51ld.fsf@users.sourceforge.net> <5A0403AE.6020305@gmx.at> Date: Thu, 09 Nov 2017 08:20:34 -0500 In-Reply-To: <5A0403AE.6020305@gmx.at> (martin rudalics's message of "Thu, 09 Nov 2017 08:28:46 +0100") Message-ID: <87po8r4mhp.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) martin rudalics writes: >>> But as long as a user doesn't switch to that workspace she won't observe >>> that making a new frame is slower. So I seem to be missing something. >> >> She can observe it indirectly via lisp code. > > But Alexander said > > Furthermore, other operations like navigation across windows or > performing an incremental search are also noticeably slower, i.e. they > stutter annoyingly, and from what I see is a result of extensive GC > spam which did not occur in previous versions. Looks like something > > so he must have had a direct, immediate experience. Ah, perhaps you missed it, that's actually a separate problem. See latter halves of #22 & #25. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29095#22 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29095#25 >> I would still like to phase it out. Maybe we could set the default to >> nil for Emacs 27? > > I'd set the default to nil for the release. Did we have any open bugs > when you added that option? As far as I know, the only cases of trouble due to not waiting were Bug#25521 and Bug#25511. I would note that the dependency on frame visibility is somewhat non-obvious in both cases (the dependency in the #25521 case is now eliminated by changing select-frame-by-name). So talking about visibility in etc/PROBLEMS is not necessarily of much use. From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2017 18:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Noam Postavsky Cc: 29095@debbugs.gnu.org, Alexander Shukaev Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.15102511893362 (code B ref 29095); Thu, 09 Nov 2017 18:14:02 +0000 Received: (at 29095) by debbugs.gnu.org; 9 Nov 2017 18:13:09 +0000 Received: from localhost ([127.0.0.1]:60728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCrK9-0000sA-FF for submit@debbugs.gnu.org; Thu, 09 Nov 2017 13:13:09 -0500 Received: from mout.gmx.net ([212.227.17.22]:50538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCrK7-0000rx-U3 for 29095@debbugs.gnu.org; Thu, 09 Nov 2017 13:13:08 -0500 Received: from [192.168.1.100] ([46.125.250.80]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LpsmR-1eq1tT2AhL-00fkX9; Thu, 09 Nov 2017 19:12:52 +0100 Message-ID: <5A049A98.8020901@gmx.at> Date: Thu, 09 Nov 2017 19:12:40 +0100 From: martin rudalics MIME-Version: 1.0 References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> <5A02AE92.6010201@gmx.at> <87vaik51ld.fsf@users.sourceforge.net> <5A0403AE.6020305@gmx.at> <87po8r4mhp.fsf@users.sourceforge.net> In-Reply-To: <87po8r4mhp.fsf@users.sourceforge.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:akqBdcbIRCu7qvSo8MtkcQ8W0Ohue91goXG+QhIHNw4jeWtEqpQ PWOPBIUE+2P0IbKSk6h9xXcm+Pbmtcg9TQ344qKfBoRekY1Y3JtMuiGSbRJ80BNblBO0gY1 gvtQ1n/3jc+xCwQraXUssGHWjZwKN3EUK7HkJc9NikQb6WiuKYHguWXpnSKUUbbep5/kGlf 7XP7KNaP2Py9foYNz+gCw== X-UI-Out-Filterresults: notjunk:1;V01:K0:t720WozIoEY=:cgAivN5t3UdoBrrQPicgZV Jl5m1Jvvsy5kqc59F0ZAJygfO2XjFIOnQIDy1qwcopk1xPylW2ubYexkL4S55CqF4MiSwPXvH PjuOn/mD2ruPaF7PUk/vzHdOCb0ty1reou+3fuBAau/OX94CxAr0X4y91N2C13kLjRHcSqR6e YCcGiLc37qh2vUK/kr5Ac86tV7CRmeJaqPJeuAHyWAzBFsOqmF48Pk7coQZWkKuE3rtritJpp meUeh007vJ/G4XHjd6WXyl3lo44s/n+HIQ8P7RuJk2Le6XMC+EnQSXfmRaT1bqvWD+tq4V39X 0VaZQg+3b4XgdzFiJF5A+m+wetLIRYLe/cRODWfKIGTIyZkLY0+GR/8hnffdZPolqtHlZDH5V Bt6mwYiqd7s7ir2Wr4nio0Cz7YBYDmhx6CSldMYul7UmUAhbuBMw7zlvNHafdNnb5Fz/+XejK r6vIq53udXQoMEHVdTaxpBs2exBLrPZoLrwkXFvnm8fNrXRgJCM8hKO6rYe/9RxUPcF8/Gvgf vdxFOrkCFwRy7FZ41YSGRx+cjRbcRL4/TmKPXpt5RjH8ai2cnz8jUO8UsissXp6Z8z/BPsFKn xEc3tTJErU7PGNjLUNjx5bRgwB1Iy+Sl3oyE88VkDe0/BrvWspNEYf6HzJAXUFlfkH1a3370j CM4piY1W71Tmb+W5VNKxCRULxxjwP048x1TTP/zDeJz+PeU9CUgGHS4HkLX5Un2ViRg6sM42g /76H/x/IvOpi/+yFBXJiJ7a/3jH947Jkisa80a3lYPXfsNkaxb/UlrYHYUEPZv6jzLbgjFGAp eVjXd0MZczT3/vemjbHYut9fzsMbOtkr91Bii2jAl8EnyEYlEKYTRqkMTJZ71uEB7tWjl/d X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.5 (---) >> But Alexander said >> >> Furthermore, other operations like navigation across windows or >> performing an incremental search are also noticeably slower, i.e. they >> stutter annoyingly, and from what I see is a result of extensive GC >> spam which did not occur in previous versions. Looks like something >> >> so he must have had a direct, immediate experience. > > Ah, perhaps you missed it, that's actually a separate problem. See > latter halves of #22 & #25. > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29095#22 > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29095#25 I didn't miss those and I have no explanation why his minibuffer doesn't show up Do you? > As far as I know, the only cases of trouble due to not waiting were > Bug#25521 and Bug#25511. And we closed them both. > I would note that the dependency on frame visibility is somewhat > non-obvious in both cases (the dependency in the #25521 case is now > eliminated by changing select-frame-by-name). So talking about > visibility in etc/PROBLEMS is not necessarily of much use. IIUC we have three issues here: (1) Since we always used some sort of waiting, some code that relied on its presence but (IMHO) should never have been written that way, was executed as intended by the author. Bug#25521 was such a case. I think this issue should be fixed by supplying the entire available information (like the expected frame size or the asked for name) at the time the frame is created. If anything changes later, we'll inform about that change in due time. (2) Apparently sometimes the window system / manager does not inform us that a frame has become visible although the frame apparently has become visible. If I'm not mistaken that's what Alexander sees (or is not able to see). (3) Sometimes for a frame it may take forever to become visible. That's the case you cited earlier with a frame that is expected to pop up on a different workspace. In some sense all of these are problems we have not completely resolved for at least one sort of timeout a user chooses. martin From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Alexander Shukaev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2017 22:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: martin rudalics , Noam Postavsky Cc: 29095@debbugs.gnu.org Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.151026539322471 (code B ref 29095); Thu, 09 Nov 2017 22:10:02 +0000 Received: (at 29095) by debbugs.gnu.org; 9 Nov 2017 22:09:53 +0000 Received: from localhost ([127.0.0.1]:60965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCv1F-0005qN-5t for submit@debbugs.gnu.org; Thu, 09 Nov 2017 17:09:53 -0500 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:41507) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCv1C-0005qC-PU for 29095@debbugs.gnu.org; Thu, 09 Nov 2017 17:09:51 -0500 X-Originating-IP: 88.69.40.141 Received: from [192.168.2.109] (dslb-088-069-040-141.088.069.pools.vodafone-ip.de [88.69.40.141]) (Authenticated sender: forum@alexander.shukaev.name) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id A3D97C5A51; Thu, 9 Nov 2017 23:09:48 +0100 (CET) References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> <5A02AE92.6010201@gmx.at> <87vaik51ld.fsf@users.sourceforge.net> <5A0403AE.6020305@gmx.at> <87po8r4mhp.fsf@users.sourceforge.net> <5A049A98.8020901@gmx.at> From: Alexander Shukaev Message-ID: Date: Thu, 9 Nov 2017 23:09:47 +0100 MIME-Version: 1.0 In-Reply-To: <5A049A98.8020901@gmx.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi guys, On 11/09/2017 07:12 PM, martin rudalics wrote: > (2) Apparently sometimes the window system / manager does not inform us > that a frame has become visible although the frame apparently has become > visible.  If I'm not mistaken that's what Alexander sees (or is not able > to see). Apologies for the delay, I was off to another town for a couple of days. So let me provide some more details of what's going on and what is the use case. It's actually nothing special, and that's why I'm also confused how nobody noticed that before. All I do is just start new Emacs instance. My (tiling) window manager is BSPWM . Now let's see what happens when - `minibuffer-auto-raise' is nil, - `x-wait-for-event-timeout' is 0.1 (default): NOTE: [after-init] marks the point in time when executions of all functions attached to `after-init-hook' are finished. (... *cough* ... I got tons of packages, sorry ... *cough* ... ) Initializing... Loading ~/.emacs.d/init.el... Loading tramp...done Loading ~/.custom.el...done Compiling ~/.emacs.d/init/... Checking ~/.emacs.d/init/... [181 times] Done (Total of 0 files compiled, 180 skipped) Compiling ~/.emacs.d/init/...done Configuring package auto-compile...done Loading package with-after-load... Configuring package with-after-load...done Loading package with-after-load...done Configuring package menu-bar...done Configuring package tool-bar...done Configuring package scroll-bar...done Configuring package simple...done Configuring package button...done Configuring package completion-list...done Configuring package mouse...done Configuring package special...done Configuring package tabulated-list...done Configuring package font-lock...done Configuring package fill...done Configuring package auto-fill...done Configuring package newcomment...done Configuring package wid-edit...done Configuring package window...done Configuring package minibuffer...done Configuring package minibuffer-line...done Configuring package easymenu...done Configuring package eldoc...done Configuring package elisp-mode...done Configuring package lisp-mode...done Configuring package prog-mode...done Configuring package text-mode...done Configuring package files...done Loading package git... Configuring package git...done Loading package git...done Configuring package ansi-color...done Configuring package comint...done Configuring package shell...done Configuring package select...done Loading package dired... Configuring package dired...done Loading package dired...done Configuring package dired-x...done Configuring package compile...done Configuring package elec-pair...done Configuring package mb-depth...done Configuring package tramp...done Configuring package password-cache...done Configuring package vc-hooks...done Loading ~/.emacs.d/init.el...done (2.808s) Initializing...done (3.256s) Configuring package evil-vars...done Configuring package evil-core...done Configuring package evil-states...done Configuring package evil-search...done Configuring package evil... Configuring package evil-surround...done Configuring package evil...done Configuring package devil-vars...done Configuring package devil-ex...done Configuring package avy...done Configuring package devil-maps...done Configuring package devil...done Configuring package flx...done Configuring package ivy...done Configuring package counsel...done Configuring package savehist...done Configuring package server...done Configuring package hl-todo...done Configuring package hl-line...done Configuring package recentf... Loading ~/.emacs.d/.recentf.el (source)...done Configuring package recentf-ext...done Configuring package sync-recentf...done Configuring package recentf...done (0.135s) Configuring package help-mode...done Configuring package with-editor...done Configuring package git-commit...done Configuring package pdf-tools...done Configuring package diff...done Configuring package undo-tree...done Configuring package ycmd...done Configuring package flycheck...done Configuring package flycheck-ycmd...done Configuring package php-extras...done Configuring package company...done Configuring package company-ycmd...done Configuring package company-flx...done Configuring package paren...done Configuring package highlight-escape-sequences...done Loading ~/.emacs.d/init.el...done (6.496s) [after-init] Notice how configuring of package `recentf' suddenly appears to stand out and it contains that single 100 ms delay. Curiously no matter how many times I restart Emacs, it's always `recentf' that gets this delay. I have no idea why but it's for sure related. Anyway, let's disregard it for a moment and assume that it is still fine. Now let's see what happens when - `minibuffer-auto-raise' is t, - `x-wait-for-event-timeout' is 0.1 (default): Initializing... Loading ~/.emacs.d/init.el... Loading tramp...done Loading ~/.custom.el...done Compiling ~/.emacs.d/init/... Checking ~/.emacs.d/init/... [181 times] Done (Total of 0 files compiled, 180 skipped) Compiling ~/.emacs.d/init/...done Configuring package auto-compile...done Loading package with-after-load... Configuring package with-after-load...done Loading package with-after-load...done Configuring package menu-bar...done Configuring package tool-bar...done Configuring package scroll-bar...done Configuring package simple...done Configuring package button...done Configuring package completion-list...done Configuring package mouse...done Configuring package special...done Configuring package tabulated-list...done Configuring package font-lock...done Configuring package fill...done Configuring package auto-fill...done Configuring package newcomment...done Configuring package wid-edit...done Configuring package window...done --------------------------------------------------------- >>> *minibuffer-auto-raise is set to t at this point* <<< --------------------------------------------------------- Configuring package minibuffer-line...done (0.106s) Configuring package easymenu...done (0.102s) Configuring package eldoc...done (0.103s) Configuring package elisp-mode...done (0.104s) Configuring package lisp-mode...done (0.103s) Configuring package prog-mode...done (0.104s) Configuring package text-mode...done (0.104s) Configuring package files...done (0.104s) Loading package git... Configuring package git...done (0.103s) Loading package git...done (0.336s) Configuring package ansi-color...done (0.104s) Configuring package comint...done (0.105s) Configuring package shell...done (0.102s) Configuring package select...done (0.102s) Loading package dired... Configuring package dired...done (0.114s) Loading package dired...done (0.339s) Configuring package dired-x...done (0.102s) Configuring package compile...done (0.104s) Configuring package elec-pair...done (0.104s) Configuring package mb-depth...done (0.104s) Configuring package tramp...done (0.104s) Configuring package password-cache...done (0.104s) Configuring package vc-hooks...done (0.104s) Loading ~/.emacs.d/init.el...done (24.086s) Initializing...done (24.532s) Configuring package evil-vars...done (0.104s) Configuring package evil-core...done (0.102s) Configuring package evil-states...done (0.107s) Configuring package evil-search...done (0.103s) Configuring package evil... Configuring package evil-surround...done (0.104s) Configuring package evil...done (0.319s) Configuring package devil-vars...done (0.103s) Configuring package devil-ex...done (0.102s) Configuring package avy...done (0.102s) Configuring package devil-maps...done (0.107s) Configuring package devil...done (0.103s) Configuring package flx...done (0.103s) Configuring package ivy...done (0.107s) Configuring package counsel...done (0.104s) Configuring package savehist...done (0.104s) Configuring package server...done (0.103s) Configuring package hl-todo...done (0.103s) Configuring package hl-line...done (0.104s) Configuring package recentf... Loading ~/.emacs.d/.recentf.el (source)...done Configuring package recentf-ext...done (0.104s) Configuring package sync-recentf...done (0.103s) Configuring package recentf...done (15.669s) Configuring package help-mode...done (0.103s) Configuring package with-editor...done (0.104s) Configuring package git-commit...done (0.105s) Configuring package pdf-tools...done (0.102s) Configuring package diff...done (0.102s) Configuring package undo-tree...done (0.105s) Configuring package ycmd...done (0.102s) Configuring package flycheck...done (0.103s) Configuring package flycheck-ycmd...done (0.105s) Configuring package php-extras...done (0.104s) Configuring package company...done (0.106s) Configuring package company-ycmd...done (0.104s) Configuring package company-flx...done (0.104s) Configuring package paren...done (0.104s) Configuring package highlight-escape-sequences...done (0.104s) Loading ~/.emacs.d/init.el...done (53.348s) [after-init] Look how as soon as `minibuffer-auto-raise' is set to t, configurations of all subsequent packages obviously get delayed by 100 ms each. This is most probably caused by the messages being written to minibuffer. When - `x-wait-for-event-timeout' is nil, there are no additional delays at all. Regards, Alexander From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Alexander Shukaev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Nov 2017 22:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: martin rudalics , Noam Postavsky Cc: 29095@debbugs.gnu.org Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.151026612823668 (code B ref 29095); Thu, 09 Nov 2017 22:23:01 +0000 Received: (at 29095) by debbugs.gnu.org; 9 Nov 2017 22:22:08 +0000 Received: from localhost ([127.0.0.1]:60986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCvD6-00069g-Jy for submit@debbugs.gnu.org; Thu, 09 Nov 2017 17:22:08 -0500 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:47717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCvD5-00069Z-5T for 29095@debbugs.gnu.org; Thu, 09 Nov 2017 17:22:07 -0500 X-Originating-IP: 88.69.40.141 Received: from [192.168.2.109] (dslb-088-069-040-141.088.069.pools.vodafone-ip.de [88.69.40.141]) (Authenticated sender: forum@alexander.shukaev.name) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 2F5D5E82; Thu, 9 Nov 2017 23:22:04 +0100 (CET) From: Alexander Shukaev References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> <5A02AE92.6010201@gmx.at> <87vaik51ld.fsf@users.sourceforge.net> <5A0403AE.6020305@gmx.at> <87po8r4mhp.fsf@users.sourceforge.net> <5A049A98.8020901@gmx.at> Message-ID: Date: Thu, 9 Nov 2017 23:22:03 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 11/09/2017 11:09 PM, Alexander Shukaev wrote: > - `x-wait-for-event-timeout' is nil, there are no additional delays at all. Ha, I take this last phrase back. It's actually getting interesting, in fact, when `x-wait-for-event-timeout' is nil: Configuring package recentf...done (0.365s) but with `x-wait-for-event-timeout' being 0.1: Configuring package recentf...done (0.131s) it's back to lower again. Whaaat? From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Nov 2017 00:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Alexander Shukaev Cc: 29095@debbugs.gnu.org, martin rudalics Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.151027520420148 (code B ref 29095); Fri, 10 Nov 2017 00:54:01 +0000 Received: (at 29095) by debbugs.gnu.org; 10 Nov 2017 00:53:24 +0000 Received: from localhost ([127.0.0.1]:32908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCxZU-0005Eu-9S for submit@debbugs.gnu.org; Thu, 09 Nov 2017 19:53:24 -0500 Received: from mail-it0-f46.google.com ([209.85.214.46]:56367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCxZQ-0005Eg-W0 for 29095@debbugs.gnu.org; Thu, 09 Nov 2017 19:53:21 -0500 Received: by mail-it0-f46.google.com with SMTP id r127so12939268itb.5 for <29095@debbugs.gnu.org>; Thu, 09 Nov 2017 16:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=rkO40CjBWsVphxvb6ZUeWWrRv15m8F9tRoX3ZsnqoBw=; b=cVFYwuDVIXWr2mSTb0CyeHQE1zk1npDgtVvkAUdMl2Hdoa8kyYfindf6S3a/8MPmJc uyEwQk5iOpNk3ICDj7yLcJCyO93d4Zc42u3Fj8KwbQDIywawcbrON5Zc6WQGRlDbNa1+ NVR3JTdF/9gbY3u2m0UfK6AzhjB6guJqZERx03o6Oiwlp8vRvj3qmpaTG1+PHC8Fyxf9 dqIRFHhbaNfgmbUYrOd+UKWcJ/uz6W0Q8rYMzRxGWkc5fIorZC2cMF1aMYRIwKcVbZEp VE0g8hlNGgN5jb0q8xPNXCArjZW7bweXt4tSAOfixE/WwEmRRYWyZGwUAr+FGqip7bcE l/wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding; bh=rkO40CjBWsVphxvb6ZUeWWrRv15m8F9tRoX3ZsnqoBw=; b=qJVbNCwcKV0sehckXpu0NUXxlKKfrueiDYL14stj23G7H9/BO7wb/tq+Ig6CliKoJM zRBfkEGzew+sWZd0SwW+iZB1kMvlHMKHP24BaZ1EdhfR4bZolF3Gpi/HOk+smEd5YP3w eD6x9J9CdlhfJeYKWw4kQz8JIWrZ10wXIIO412xynfm07D9GXQJIv2sOVE9Bdq657mq3 3XSzXqQZSdmd2v+y9odn2VK/GIfaJzHXjiSeLbzfMdZ/UloX49G2MHu7EtVxPJ3ex8Lv 93UMANSn9llHMbg/m/V+haP+2j+bxOMiuEEEAGpRQfvL/1G2njmXh93blAB91JPSGv1R I44A== X-Gm-Message-State: AJaThX6xG0RkxCBi8snkzUKzEg8rlS4darju46S3COpMSUXruI7uzmyS GC+6V5e/uRpJ0TBj+1CBiCedZA== X-Google-Smtp-Source: AGs4zMZ/kFUDoQl89dIDLHrfUAFWiEq+QvqktwlJrJ+4kdN5WollWD2r0Zk0s+77ZPgW77LgRvdWNw== X-Received: by 10.36.83.202 with SMTP id n193mr2319400itb.134.1510275195043; Thu, 09 Nov 2017 16:53:15 -0800 (PST) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id 80sm4037849ioz.54.2017.11.09.16.53.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Nov 2017 16:53:14 -0800 (PST) From: Noam Postavsky References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> <5A02AE92.6010201@gmx.at> <87vaik51ld.fsf@users.sourceforge.net> <5A0403AE.6020305@gmx.at> <87po8r4mhp.fsf@users.sourceforge.net> <5A049A98.8020901@gmx.at> Date: Thu, 09 Nov 2017 19:53:13 -0500 In-Reply-To: (Alexander Shukaev's message of "Thu, 9 Nov 2017 23:09:47 +0100") Message-ID: <87d14r3qfa.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Alexander Shukaev writes: > Hi guys, > > On 11/09/2017 07:12 PM, martin rudalics wrote: >> (2) Apparently sometimes the window system / manager does not inform us >> that a frame has become visible although the frame apparently has become >> visible.=C2=A0 If I'm not mistaken that's what Alexander sees (or is not= able >> to see). > > Apologies for the delay, I was off to another town for a couple of > days. So let me provide some more details of what's going on and what > is the use case. It's actually nothing special, and that's why I'm > also confused how nobody noticed that before. All I do is just start > new Emacs instance. My (tiling) window manager is BSPWM > . Do you have the Emacs instance showing up in a different virtual desktop, or somehow prevent it from becoming visible immediately? It could be that this window manager somehow prevents Emacs from getting the expected events to udpate frame visibility correctly. > Notice how configuring of package `recentf' suddenly appears to stand > out and it contains that single 100 ms delay. Curiously no matter how > many times I restart Emacs, it's always `recentf' that gets this > delay. I have no idea why but it's for sure related. I suppose either recentf and/or your configuration of it are doing something which takes a lot of time (e.g., reading from disk). > Look how as soon as `minibuffer-auto-raise' is set to t, > configurations of all subsequent packages obviously get delayed by 100 > ms each. This is most probably caused by the messages being written > to minibuffer. Right. > On 11/09/2017 11:09 PM, Alexander Shukaev wrote: >> - `x-wait-for-event-timeout' is nil, there are no additional delays at a= ll. > > Ha, I take this last phrase back. It's actually getting interesting, > in fact, when `x-wait-for-event-timeout' is nil: > > Configuring package recentf...done (0.365s) > > but with `x-wait-for-event-timeout' being 0.1: > > Configuring package recentf...done (0.131s) > > it's back to lower again. Whaaat? Is this consistent, or perhaps just a fluke? From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Nov 2017 10:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Alexander Shukaev , Noam Postavsky Cc: 29095@debbugs.gnu.org Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.15104813757327 (code B ref 29095); Sun, 12 Nov 2017 10:10:02 +0000 Received: (at 29095) by debbugs.gnu.org; 12 Nov 2017 10:09:35 +0000 Received: from localhost ([127.0.0.1]:36029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eDpCp-0001u7-AD for submit@debbugs.gnu.org; Sun, 12 Nov 2017 05:09:35 -0500 Received: from mout.gmx.net ([212.227.17.22]:59797) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eDpCn-0001tv-V2 for 29095@debbugs.gnu.org; Sun, 12 Nov 2017 05:09:34 -0500 Received: from [192.168.1.100] ([46.125.250.81]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MC8iq-1eMeuG1dIm-008nbG; Sun, 12 Nov 2017 11:09:20 +0100 Message-ID: <5A081DCA.3070303@gmx.at> Date: Sun, 12 Nov 2017 11:09:14 +0100 From: martin rudalics MIME-Version: 1.0 References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> <5A02AE92.6010201@gmx.at> <87vaik51ld.fsf@users.sourceforge.net> <5A0403AE.6020305@gmx.at> <87po8r4mhp.fsf@users.sourceforge.net> <5A049A98.8020901@gmx.at> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:lN4Psx017oulOqoFUAM3T1m31XY+0OeMMMKSmRPqOVCdu//Mfbi Xcb0wACxhaeT03ICbPlVfCfrnof+lAMNA3zBiL0BuWW8zAr8iaWHHjOcYE/qTPzUwmhnblN k8V4HYkb8eJ0MDcfRsdZ4q3vyls30vAst8etLD2ro2c3qbU+kEZbMEw1B6iF22X1MntCkUl /Tu0hX5Yo9ThbFSUVeT1Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:CSOLKAiP+nM=:a2O23Jp2FoPO0Wk6wGZ62Y XT3elb7YVJXriaSm2qNaCYhwxZHQZKxw0FDGqgJ929q/BTSOfVbrmzp9h8Xt0JaPceMlUjxhv NM3CBvUCZutXFHvychxUjm54FQ55SkoEhr5dnNQVbnfYSYTlaWR2XGb66Ymx6zaKAqkEzkVAS rKZlrz5+5oV2CwmFE41k9fLADCJPXdgMpphykttYK+LVy1k8/diN+Vofs/A4pjNAhqo3Pb9y+ Q7kMtpeQKtEhw4tNWfyBsY6gMIV/30PY1eQc1PVF4oS+CdTQwh65rJCduQCGH36EOEtqv7HMK yPTqlv3BgKVIA6iquvf5cS3b6Kc3Id6nahI4yny+/tJ4CyYYYhubCa66GTupDdBX5kTsQwHAM nwVJBxqeS1KnoyFJisJFcWaB7TErKRgXv0ZH7fbAzpOwnHw0uBMHsFeDmANkuR0EQni/l2LLB EgjCW+FXcsj/nxEDaduKZmSQSVQ1PithX67LMU9QNRaPXPYk/3sOnJIF/nXbPP6T7iML60R5X QV1lAVnnA/WBJlx1lZkV2/8KfxsqNlPZKXy3mGizP+yHGn6FAIJwzOgEcFMBREtFiSrYruMgw KrWgImRnb2cttOxiO8wouW9zYG6ZkHZTEcVLNi3bI2Ws2DOvpRvCjNVDKA+73wMn7KqPQoveF fHFZ4W8a1VCdAXrCJdzoQSXmgc5+c32S/w49rsb/Ap4j5NIFyLG6X5RQloztpn6OvmpFWzcrx 5bA0NLSIG05ForeeB4toPt0CrnlA5nCwBk3Ib7i5JvM9nhUaTstBd9IxPnJ7mMDOLOl7vbcO/ RIAloo9D47ttlEV836XjCfQBHfAOawV4v9rh5VwWKDztDitgtA6H4Ps2w46zRKDRqgYv4Gg X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.5 (---) > My (tiling) window manager is BSPWM > . Now let's see what happens > when > - `minibuffer-auto-raise' is nil, > - `x-wait-for-event-timeout' is 0.1 (default): [...] > Configuring package minibuffer...done > Configuring package minibuffer-line...done Using a tiling window manager plus =E2=80=98minibuffer-auto-raise=E2=80=99= plus =E2=80=98minibuffer-line=E2=80=99 is about the worst case scenario I coul= d only imagine. In practice, it means that all visible windows on your desktop may have to be resized whenever an Emacs message is shown or the contents of the modeline of the selected Emacs window changes. > Configuring package recentf... > Loading ~/.emacs.d/.recentf.el (source)...done > Configuring package recentf-ext...done > Configuring package sync-recentf...done > Configuring package recentf...done (0.135s) [...] > > Notice how configuring of package `recentf' suddenly appears to stand > out and it contains that single 100 ms delay. Curiously no matter how= > many times I restart Emacs, it's always `recentf' that gets this > delay. I have no idea why but it's for sure related. Anyway, let's > disregard it for a moment and assume that it is still fine. Now let's= > see what happens when As I never configure any packages I don't understand what you're doing. For example, I have no idea what configuring packages like "simple" or "window" does. But note that recentf.el is the only one of your "packages" loaded from source and descends into two sub-packages (or whatever these are) before completing. And obviously it might look into the availability of your recent files which could take some time. > Configuring package window...done > --------------------------------------------------------- > >>> *minibuffer-auto-raise is set to t at this point* <<< > --------------------------------------------------------- > Configuring package minibuffer-line...done (0.106s) Who sets that and what happened to the Configuring package minibuffer...done line? > Look how as soon as `minibuffer-auto-raise' is set to t, > configurations of all subsequent packages obviously get delayed by 100= > ms each. This is most probably caused by the messages being written > to minibuffer. Sure. I suppose your window manager is in heavy troubles. Why can't you delay setting =E2=80=98minibuffer-auto-raise=E2=80=99 at least until = after loading is complete? martin From unknown Mon Jun 23 18:31:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Apr 2019 02:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29095 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: 29095@debbugs.gnu.org Cc: martin rudalics , Alexander Shukaev Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.15559879548112 (code B ref 29095); Tue, 23 Apr 2019 02:53:02 +0000 Received: (at 29095) by debbugs.gnu.org; 23 Apr 2019 02:52:34 +0000 Received: from localhost ([127.0.0.1]:52089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hIlXu-00026g-6E for submit@debbugs.gnu.org; Mon, 22 Apr 2019 22:52:34 -0400 Received: from mail-qk1-f178.google.com ([209.85.222.178]:42168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hIlXr-00026O-Sa; Mon, 22 Apr 2019 22:52:32 -0400 Received: by mail-qk1-f178.google.com with SMTP id c190so3927075qke.9; Mon, 22 Apr 2019 19:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=DrWQ8BPdJHtxBwhago7Kp9mphA2wWGVDU1NHydFiwhA=; b=S0tQjvRQDURpWGEjCx3RyVQRlqQLFCrJM0IgVFkQnrJXbXkpCQyuYwkZllAvPQ93jv ekwx+Zf8d0mvd8bnSh85YsmGmdy4TA+42ctt338nZAJGshI0KdBydW2V9c3KZVYACwFY rz5DV81YLm4/TrZFReP+Y0qPbrH3dwlWFixiuuINkV6moPEmWw2vsOR18sdNvmTqdfEz Fy4xRnVl9l1ZJHous9tD6c0bLWoEWbB+L/gCAv/XhGtaarYIqH+3iZcWF6d8O3bxJwsZ EpVTUfnyFALehsDeq/tfgLsrVw8hY2+tAtgyHLATPlkqhuzMci2/WQvcIpHUn7Lwr/RS oGKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=DrWQ8BPdJHtxBwhago7Kp9mphA2wWGVDU1NHydFiwhA=; b=i+v+r66UpaeOR1oZzOfoOAimET+snnkAvtZyGOZjxWwE6pK4pekLvJgGuzPoGfQlq1 v7kx2W/QRgkSUSXefhEUexG6eEy3iDV24TfWs/gwS/JyAVlyh5NzGnvHEkYRyT1Rsg+u T4Do3WMIW4tsMa3I4KTsaSJnVgnUeSYVdzi8U7NPDdSEiquyYxJGlZX2WZM4MAhxr1cH u9zO3WmJ8MJ2DrW6Y9YoIsJ+uj2JQ3N0Jd4YQw+Pi65kVnreCKe0esP11Q2eh7Cwz6V2 n9JSmkEt7X0l+BUNfm3jl1t1OrRpzARv/HekPIIxEt9i18+CyEOE0FPUQYikBfU6+amO z5jA== X-Gm-Message-State: APjAAAUBwEbvDmXbXsVqObplY0x6qCeBytrvXx2efYmYFtzJrcRdU+JT KDMzy0Gtxumo6Xk+7/uo7htO3PPM X-Google-Smtp-Source: APXvYqwDYq13K9nXDBIGYjJHqqDC3vi3ogx4nAN0jKQ6F6Xr1Ne5cE9PNm6BiXyOGI7v+6z64pyzSQ== X-Received: by 2002:a37:7401:: with SMTP id p1mr2178753qkc.172.1555987946117; Mon, 22 Apr 2019 19:52:26 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.googlemail.com with ESMTPSA id f47sm9211359qta.80.2019.04.22.19.52.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 22 Apr 2019 19:52:24 -0700 (PDT) From: Noam Postavsky References: <0899d792-c1fe-caa8-183e-298371d226a0@Alexander.Shukaev.name> <87h8ueaioy.fsf@users.sourceforge.net> <87zi858r9i.fsf@users.sourceforge.net> <87y3nl7g8l.fsf@users.sourceforge.net> <59FEEDA4.4040602@gmx.at> <87d14u5ua1.fsf@users.sourceforge.net> <5A02AE92.6010201@gmx.at> <87vaik51ld.fsf@users.sourceforge.net> <5A0403AE.6020305@gmx.at> <87po8r4mhp.fsf@users.sourceforge.net> <5A049A98.8020901@gmx.at> <87d14r3qfa.fsf@users.sourceforge.net> Date: Mon, 22 Apr 2019 22:52:23 -0400 In-Reply-To: <87d14r3qfa.fsf@users.sourceforge.net> (Noam Postavsky's message of "Thu, 09 Nov 2017 19:53:13 -0500") Message-ID: <877eblsaag.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 29095 quit Noam Postavsky writes: > Do you have the Emacs instance showing up in a different virtual > desktop, or somehow prevent it from becoming visible immediately? It > could be that this window manager somehow prevents Emacs from getting > the expected events to udpate frame visibility correctly. >> Ha, I take this last phrase back. It's actually getting interesting, >> in fact, when `x-wait-for-event-timeout' is nil: >> >> Configuring package recentf...done (0.365s) >> >> but with `x-wait-for-event-timeout' being 0.1: >> >> Configuring package recentf...done (0.131s) >> >> it's back to lower again. Whaaat? > > Is this consistent, or perhaps just a fluke? Seems we're not going to get any more answers. Closing.