bug#20445: excessive redisplay / echo area resizing during byte-compilation

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Glenn Morris]

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.)

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Glenn Morris]

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.

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[martin rudalics]

 > 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

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[martin rudalics]

 > 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

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Eli Zaretskii]

> From: Glenn Morris <rgm@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.

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Eli Zaretskii]

> Date: Tue, 28 Apr 2015 16:26:14 +0200
> From: martin rudalics <rudalics@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?

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[martin rudalics]

 > 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

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Eli Zaretskii]

> Date: Tue, 28 Apr 2015 19:43:03 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: rgm@gnu.org, 20445@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?

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Stefan Monnier]

>     (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

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[martin rudalics]

 > 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

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[martin rudalics]

 > 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

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Artur Malabarba]

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

> >     (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))

[-- Attachment #2: Type: text/html, Size: 748 bytes --]

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Artur Malabarba]

2015-04-29 8:11 GMT+01:00 martin rudalics <rudalics@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.

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Artur Malabarba]

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.

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 28 Apr 2015 23:21:16 -0400
> Cc: 20445@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?

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Artur Malabarba]

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.

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Artur Malabarba]

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@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.

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[martin rudalics]

 > 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

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[martin rudalics]

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

Why?

martin

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Artur Malabarba]

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

On May 1, 2015 11:41 AM, "martin rudalics" <rudalics@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.

[-- Attachment #2: Type: text/html, Size: 897 bytes --]

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[martin rudalics]

 > 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

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Artur Malabarba]

>> 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.

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[Artur Malabarba]

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

Fixed by reverting the following commits.

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

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

[-- Attachment #2: Type: text/html, Size: 301 bytes --]

bug#20445: excessive redisplay / echo area resizing during byte-compilation

[martin rudalics]

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

Thank you.

martin