From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.bugs Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Date: Wed, 08 Nov 2017 08:42:06 -0500 Message-ID: <87vaik51ld.fsf@users.sourceforge.net> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1510148597 32659 195.159.176.226 (8 Nov 2017 13:43:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Nov 2017 13:43:17 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) Cc: 29095@debbugs.gnu.org, Alexander Shukaev To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 08 14:43:12 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCQdK-0008Cs-6g for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Nov 2017 14:43:10 +0100 Original-Received: from localhost ([::1]:59700 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCQdR-0001r4-FT for geb-bug-gnu-emacs@m.gmane.org; Wed, 08 Nov 2017 08:43:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCQdG-0001qx-Kk for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 08:43:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCQdC-0005Uy-VL for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 08:43:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49053) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eCQdC-0005Uo-Qx for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 08:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eCQdC-0007Jh-EA for bug-gnu-emacs@gnu.org; Wed, 08 Nov 2017 08:43:02 -0500 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 29095-submit@debbugs.gnu.org id=B29095.151014853528067 (code B ref 29095); Wed, 08 Nov 2017 13:43:02 +0000 Original-Received: (at 29095) by debbugs.gnu.org; 8 Nov 2017 13:42:15 +0000 Original-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 Original-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 Original-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) Original-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) In-Reply-To: <5A02AE92.6010201@gmx.at> (martin rudalics's message of "Wed, 08 Nov 2017 08:13:22 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:139608 Archived-At: 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?