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.