unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Noam Postavsky <npostavs@users.sourceforge.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 29095@debbugs.gnu.org, Alexander Shukaev <emacs@Alexander.Shukaev.name>
Subject: bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s
Date: Tue, 07 Nov 2017 04:10:14 -0500	[thread overview]
Message-ID: <87d14u5ua1.fsf@users.sourceforge.net> (raw)
In-Reply-To: <59FEEDA4.4040602@gmx.at> (martin rudalics's message of "Sun, 05 Nov 2017 11:53:24 +0100")

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

martin rudalics <rudalics@gmx.at> 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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1539 bytes --]

From 9ab2cb84378dd73bd599a8445c32e305bb342819 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
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


  reply	other threads:[~2017-11-07  9:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01  0:44 bug#29095: Bug: The '20a09de953f437109a098fa8c4d380663d921481' merge increased my Emacs configuration loading time from 9 s to 60 s Alexander Shukaev
2017-11-01  1:31 ` Noam Postavsky
2017-11-01 23:49   ` Alexander Shukaev
2017-11-02  0:21     ` Noam Postavsky
2017-11-04 23:28       ` Alexander Shukaev
2017-11-04 23:53         ` Noam Postavsky
2017-11-04 23:58           ` Alexander Shukaev
2017-11-05 10:53           ` martin rudalics
2017-11-07  9:10             ` Noam Postavsky [this message]
2017-11-07 12:57               ` Noam Postavsky
2017-11-08  7:13               ` martin rudalics
2017-11-08 13:42                 ` Noam Postavsky
2017-11-09  7:28                   ` martin rudalics
2017-11-09 13:20                     ` Noam Postavsky
2017-11-09 18:12                       ` martin rudalics
2017-11-09 22:09                         ` Alexander Shukaev
2017-11-09 22:22                           ` Alexander Shukaev
2017-11-10  0:53                           ` Noam Postavsky
2019-04-23  2:52                             ` Noam Postavsky
2017-11-12 10:09                           ` martin rudalics
2017-11-08  7:13               ` martin rudalics
2017-11-01  3:44 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d14u5ua1.fsf@users.sourceforge.net \
    --to=npostavs@users.sourceforge.net \
    --cc=29095@debbugs.gnu.org \
    --cc=emacs@Alexander.Shukaev.name \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).