GNU bug report logs - #20445
excessive redisplay / echo area resizing during byte-compilation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20445 in the body.
You can then email your comments to 20445 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: excessive redisplay / echo area resizing during byte-compilation
Date: Mon, 27 Apr 2015 17:31:28 -0400

Package: emacs
Version: 25.0.50

Current master on RHEL 7.1, Lucid toolkit, without toolkit-scroll-bars.

emacs -Q ./lisp/org/org.el

menu-bar, emacs-lisp, byte-compile this file

During compilation, the display flickers a lot.
Especially noticeable in the scroll-bar.
The echo area resizes itself a lot up and down rapidly, which is pretty
distracting.

Does not happen with M-x byte-recompile-file.

Does not happen with 24.5, even with the menu-bar.


(I have a vague memory something like this happened once before not so
long ago.)

Message #8 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 20445 <at> debbugs.gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Mon, 27 Apr 2015 17:44:20 -0400

Glenn Morris wrote:

> (I have a vague memory something like this happened once before not so
> long ago.)

I think I was thinking of http://debbugs.gnu.org/16736;
but I think this issue is different to that one.

Message #11 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Glenn Morris <rgm <at> gnu.org>, 20445 <at> debbugs.gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Tue, 28 Apr 2015 11:33:51 +0200

> Current master on RHEL 7.1, Lucid toolkit, without toolkit-scroll-bars.
>
> emacs -Q ./lisp/org/org.el
>
> menu-bar, emacs-lisp, byte-compile this file
>
> During compilation, the display flickers a lot.
> Especially noticeable in the scroll-bar.
> The echo area resizes itself a lot up and down rapidly, which is pretty
> distracting.

What's your value of `resize-mini-windows'?  Here it happens only with
`resize-mini-windows' set to t.  The default 'grow-only doesn't exhibit
the problem.

martin

Message #14 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Glenn Morris <rgm <at> gnu.org>, 20445 <at> debbugs.gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Tue, 28 Apr 2015 16:26:14 +0200

> What's your value of `resize-mini-windows'?  Here it happens only with
> `resize-mini-windows' set to t.  The default 'grow-only doesn't exhibit
> the problem.

Sorry, I tested with sources from April 12th which don't exhibit this
behavior yet.  What happens is that the minibuffer is now emptied by
this part

  (unless byte-compile--interactive
    (message nil))

in `byte-compile--message' which triggers a new resize when displaying
the next message.  Try with

(defun byte-compile--message (format &rest args)
  "Like `message', except sometimes don't print to minibuffer.
If the variable `byte-compile--interactive' is nil, the message
is not displayed on the minibuffer."
  (apply #'message format args))

martin

Message #17 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 20445 <at> debbugs.gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing
 during	byte-compilation
Date: Tue, 28 Apr 2015 18:13:25 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Mon, 27 Apr 2015 17:31:28 -0400
> 
> Does not happen with M-x byte-recompile-file.

If you invoke byte-compile-file like this:

  M-: (byte-compile-file "org.el") RET

then it flickers exactly like with the menu-bar invocation.  Which is
expected, since the menu bar invokes emacs-lisp-byte-compile, which
does this:

  (defun emacs-lisp-byte-compile ()
    "Byte compile the file containing the current buffer."
    (interactive)
    (if buffer-file-name
	(byte-compile-file buffer-file-name)
      (error "The buffer must be saved in a file first")))

The difference between "M-x byte-compile-file" and the invocation via
M-: seems to be due to this trick in bytecomp.el:

  (defun byte-compile--message (format &rest args)
    "Like `message', except sometimes don't print to minibuffer.
  If the variable `byte-compile--interactive' is nil, the message
  is not displayed on the minibuffer."
    (apply #'message format args)
    (unless byte-compile--interactive
      (message nil)))

And indeed, if I invoke byte-compile-file like this:

  M-: (let ((byte-compile--interactive t)) (byte-compile-file "org.el")) RET

the flickering goes away.

Now to the source of the flickering: it's the resizing of the echo
area that causes that.  We have this code in echo_area_display:

      window_height_changed_p = display_echo_area (w);
      [...]
	  if (window_height_changed_p <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	      /* Don't do this if Emacs is shutting down.  Redisplay
	         needs to run hooks.  */
	      && !NILP (Vrun_hooks))
	    {
	      /* Must update other windows.  Likewise as in other
		 cases, don't let this update be interrupted by
		 pending input.  */
	      ptrdiff_t count = SPECPDL_INDEX ();
	      specbind (Qredisplay_dont_pause, Qt);
	      windows_or_buffers_changed = 44;  <<<<<<<<<<<<<<<<<<<<<<
	      redisplay_internal ();

And a non-zero value of windows_or_buffers_changed causes a thorough
redisplay, including, for example, the mode lines, the menu bar and
the scroll bars.

If I set resize-mini-windows to nil, the flickering disappears.

I think what causes the frequent resizes of the echo area are those
calls to (message nil) in byte-compile--message.  Perhaps avoiding
that would resolve the issue.

Otherwise, I guess I'll have to say that this is the display engine
"functioning as designed".

> Does not happen with 24.5, even with the menu-bar.

The trick with byte-compile--message and byte-compile--interactive is
new on master, it didn't exist in Emacs 24.

Message #20 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20445 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing
 during	byte-compilation
Date: Tue, 28 Apr 2015 18:22:07 +0300

> Date: Tue, 28 Apr 2015 16:26:14 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
> (defun byte-compile--message (format &rest args)
>    "Like `message', except sometimes don't print to minibuffer.
> If the variable `byte-compile--interactive' is nil, the message
> is not displayed on the minibuffer."
>    (apply #'message format args))

This effectively disables the log control executed via
byte-compile--interactive.  So the question is: how can we solve it
without that adverse effect?

Message #23 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20445 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing
 during	byte-compilation
Date: Tue, 28 Apr 2015 19:43:03 +0200

> This effectively disables the log control executed via
> byte-compile--interactive.  So the question is: how can we solve it
> without that adverse effect?

To solve the case at hand we could probably get away with something like


--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -181,7 +181,8 @@ All commands in `lisp-mode-shared-map' are inherited by this map.")
   "Byte compile the file containing the current buffer."
   (interactive)
   (if buffer-file-name
-      (byte-compile-file buffer-file-name)
+      (let ((byte-compile--interactive t))
+        (byte-compile-file buffer-file-name))
     (error "The buffer must be saved in a file first")))

 (defun emacs-lisp-byte-compile-and-load ()


But there might be lots of cases where `byte-compile-file' and friends
are called by a command.

martin

Message #26 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20445 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing
 during	byte-compilation
Date: Tue, 28 Apr 2015 21:00:33 +0300

> Date: Tue, 28 Apr 2015 19:43:03 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: rgm <at> gnu.org, 20445 <at> debbugs.gnu.org
> 
> -      (byte-compile-file buffer-file-name)
> +      (let ((byte-compile--interactive t))
> +        (byte-compile-file buffer-file-name))
>       (error "The buffer must be saved in a file first")))

Maybe we should introduce an additional value for resize-mini-windows,
which will never reset the echo area, even if it becomes empty.  Then
we could bind resize-mini-windows to that value in
emacs-lisp-byte-compile.

But I actually am not sure why (message nil) is used as a knob to
control whether echo-area messages are or aren't displayed.  Can you
explain?

Message #29 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Artur Malabarba <bruce.connor.am <at> gmail.com>
Cc: 20445 <at> debbugs.gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing
 during	byte-compilation
Date: Tue, 28 Apr 2015 23:21:16 -0400

>     (apply #'message format args)
>     (unless byte-compile--interactive
>       (message nil)))

This is the problem: in order to "not emit a message" this code emits
the message and then immediately hides it by emitting "the empty
message" on top of it.

Since `message' redisplays right away (rather than waiting for the next
"idle" moment to perform redisplay, as is the case for normal buffer
changes), this result in a lot of wasted work, and it won't truly do
what was intended:
- If your machine/display is slow enough, you will see it
- If your system "prints" messages by speaking them out loud (e.g. with
  emacspeak) you will hear them.

Why not just do:

     (when byte-compile--interactive
       (apply #'message format args))

?

        Stefan

Message #32 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20445 <at> debbugs.gnu.org, rgm <at> gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing
 during	byte-compilation
Date: Wed, 29 Apr 2015 09:11:09 +0200

> But I actually am not sure why (message nil) is used as a knob to
> control whether echo-area messages are or aren't displayed.  Can you
> explain?

Maybe (message nil) is supposed to suppress showing the previous message
in the echo area (but still keep its log somewhere).  If so, the concept
fails miserably here.

martin

Message #35 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 
 Artur Malabarba <bruce.connor.am <at> gmail.com>
Cc: 20445 <at> debbugs.gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing
 during	byte-compilation
Date: Wed, 29 Apr 2015 09:11:33 +0200

> This is the problem: in order to "not emit a message" this code emits
> the message and then immediately hides it by emitting "the empty
> message" on top of it.
>
> Since `message' redisplays right away (rather than waiting for the next
> "idle" moment to perform redisplay, as is the case for normal buffer
> changes), this result in a lot of wasted work, and it won't truly do
> what was intended:
> - If your machine/display is slow enough, you will see it
> - If your system "prints" messages by speaking them out loud (e.g. with
>    emacspeak) you will hear them.
>
> Why not just do:
>
>       (when byte-compile--interactive
>         (apply #'message format args))
>
> ?

But if there are no errors this would not display a message at all with
Glenn's scenario.  IMHO `byte-compile--interactive' puts the cart before
the horse.  Rather, displaying messages should be the default and the
caller should be able to suppress them via a `byte-compile--no-message'
variable or something the like.  So I'd instead use

  (unless byte-compile--no-message
    (apply #'message format args)))

martin

Message #38 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 20445 <at> debbugs.gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Wed, 29 Apr 2015 08:37:03 +0100

[Message part 1 (text/plain, inline)]

> >     (apply #'message format args)
> >     (unless byte-compile--interactive
> >       (message nil)))
>
> This is the problem: in order to "not emit a message" this code emits
> the message and then immediately hides it by emitting "the empty
> message" on top of it.
>
> Why not just do:
>
>      (when byte-compile--interactive
>        (apply #'message format args))

Don't we have a new inhibit-messages variable? Why not use it?

(let ((inhibit-messages (not byte-compile--interactive)))
  (apply #'message format args))

[Message part 2 (text/html, inline)]

Message #41 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20445 <20445 <at> debbugs.gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Wed, 29 Apr 2015 09:56:09 +0100

2015-04-29 8:11 GMT+01:00 martin rudalics <rudalics <at> gmx.at>:
>> This is the problem: in order to "not emit a message" this code emits
>> the message and then immediately hides it by emitting "the empty
>> message" on top of it.
>>
>> Since `message' redisplays right away (rather than waiting for the next
>> "idle" moment to perform redisplay, as is the case for normal buffer
>> changes), this result in a lot of wasted work, and it won't truly do
>> what was intended:
>> - If your machine/display is slow enough, you will see it
>> - If your system "prints" messages by speaking them out loud (e.g. with
>>    emacspeak) you will hear them.
>>
>> Why not just do:
>>
>>       (when byte-compile--interactive
>>         (apply #'message format args))
>>
>> ?
>
> But if there are no errors this would not display a message at all with
> Glenn's scenario.  IMHO `byte-compile--interactive' puts the cart before
> the horse.  Rather, displaying messages should be the default and the
> caller should be able to suppress them via a `byte-compile--no-message'
> variable or something the like.  So I'd instead use
>
>   (unless byte-compile--no-message
>     (apply #'message format args)))

I just changed the current version to use `inhibit-messages' (sorry,
forgot to reference the bug in it). I implemented
`byte-compile--message' the way that made more sense to me, but I'm
perfectly fine with your suggestion as well.

Whatever we end up doing to it, please use `(let ((inhibit-messages
byte-compile--no-message) ...)' instead of `(unless
byte-compile--no-message ...)', as that will still log the messages
somwhere.

Message #44 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20445 <20445 <at> debbugs.gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Wed, 29 Apr 2015 09:58:19 +0100

Actually, if we're going to make it so that the caller needs to
explicitly silence the compiler, then we might as well just revert to
the old behavior (no silencing) and let the caller use
`inhibit-messages' himself instead of defining a new bytecomp-specific
variable.

Message #47 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 20445 <at> debbugs.gnu.org, bruce.connor.am <at> gmail.com
Subject: Re: bug#20445: excessive redisplay / echo area
 resizing	during	byte-compilation
Date: Wed, 29 Apr 2015 18:53:22 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Tue, 28 Apr 2015 23:21:16 -0400
> Cc: 20445 <at> debbugs.gnu.org
> 
> Why not just do:
> 
>      (when byte-compile--interactive
>        (apply #'message format args))

This stops the flickering, but doesn't show any echo-area messages at
all.  Is that the intent?

Also, there's a related issue: why should
"M-x byte-compile-file RET" behave differently than
"M-x emacs-lisp-byte-compile RET" wrt to messages displayed in the
echo area?

Message #50 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20445 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Wed, 29 Apr 2015 19:35:33 +0100

I can revert that commit completely if people prefer. Then everything
should go back to what it was (and package.el will still be able to
silence the compiler on its own).

I'm all for negative coding, and I no longer think there's any use in
having a specific variable just to silence the byte-compiler.

Message #53 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20445 <20445 <at> debbugs.gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Wed, 29 Apr 2015 19:52:55 +0100

On the oher hand, it would be nice to have a way of preventing the
compilation buffer from popping up.

2015-04-29 19:35 GMT+01:00 Artur Malabarba <bruce.connor.am <at> gmail.com>:
> I can revert that commit completely if people prefer. Then everything
> should go back to what it was (and package.el will still be able to
> silence the compiler on its own).
>
> I'm all for negative coding, and I no longer think there's any use in
> having a specific variable just to silence the byte-compiler.

Message #56 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: bruce.connor.am <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>
Cc: 20445 <at> debbugs.gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Fri, 01 May 2015 12:41:51 +0200

> I can revert that commit completely if people prefer. Then everything
> should go back to what it was (and package.el will still be able to
> silence the compiler on its own).

I think this would be better, yes.

martin

Message #59 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: bruce.connor.am <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>
Cc: 20445 <20445 <at> debbugs.gnu.org>
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Fri, 01 May 2015 12:41:56 +0200

> On the oher hand, it would be nice to have a way of preventing the
> compilation buffer from popping up.

Why?

martin

Message #62 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20445 <20445 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Fri, 1 May 2015 13:20:32 +0100

[Message part 1 (text/plain, inline)]

On May 1, 2015 11:41 AM, "martin rudalics" <rudalics <at> gmx.at> wrote:
>
> > On the oher hand, it would be nice to have a way of preventing the
> > compilation buffer from popping up.
>
> Why?

Because package.el does the compilation on the user's computer, not the
developer's.

It would be nice to not bother the user with warnings that are not his
fault. All it would take is a global var to prevent the compilation window
popping up. (maybe this exists already and I don't know). The buffer can
still be created, and it can still pop-up if there's an error, but if all
we have are warnings we shouldn't be throwing them at the face of a user
who's just trying to install a package.

[Message part 2 (text/html, inline)]

Message #65 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: bruce.connor.am <at> gmail.com
Cc: 20445 <20445 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Fri, 01 May 2015 15:45:42 +0200

> It would be nice to not bother the user with warnings that are not his
> fault. All it would take is a global var to prevent the compilation window
> popping up. (maybe this exists already and I don't know).

Where and how does the compilation window get popped up?  If it's via
`display-buffer' we could try using an allow-no-window alist entry.

martin

Message #68 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20445 <20445 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Fri, 1 May 2015 15:19:43 +0100

>> It would be nice to not bother the user with warnings that are not his
>> fault. All it would take is a global var to prevent the compilation window
>> popping up. (maybe this exists already and I don't know).
>
> Where and how does the compilation window get popped up?  If it's via
> `display-buffer' we could try using an allow-no-window alist entry.

Yeah, I was doing that just now. :-) But I just found an easier way
(let ((warning-minimum-level :error)) ...).

In any case, I'll revert the messaging changes to byte-comp which
started this discussion.

Message #73 received at 20445-done <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: 20445-done <at> debbugs.gnu.org
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Fri, 1 May 2015 17:28:30 +0100

[Message part 1 (text/plain, inline)]

Fixed by reverting the following commits.

* lisp/emacs-lisp/bytecomp.el: Silence noninteractive compilations
9a7ddde977378cb5276a81476ae458889c403267.

* lisp/emacs-lisp/bytecomp.el: Use `inhibit-message'
3c0ea587daf8b17960b90603a70e3ac4057d883d.

[Message part 2 (text/html, inline)]

Message #76 received at 20445 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: bruce.connor.am <at> gmail.com
Cc: 20445 <20445 <at> debbugs.gnu.org>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#20445: excessive redisplay / echo area resizing during
 byte-compilation
Date: Sat, 02 May 2015 10:58:04 +0200

> In any case, I'll revert the messaging changes to byte-comp which
> started this discussion.

Thank you.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.