bug#5164: 23.1; message-log-max ignored by display engine

bug#5164: 23.1; message-log-max ignored by display engine

[Chong Yidong]

> The display engine writes messages to *Messages* even when
> `message-log-max' is nil (see bug #4835). This can reduce performance
> considerably in some cases.
>
> It would be good to fix this, so the variable is respected.

I can't reproduce this.  If I load the buggy column-marker.el from
Bug#4835, set message-log-max to nil, and do M-x column-marker-1, no
error messages are logged.

bug#5164: 23.1; message-log-max ignored by display engine

[Drew Adams]

> > The display engine writes messages to *Messages* even when
> > `message-log-max' is nil (see bug #4835). This can reduce 
> > performance considerably in some cases.
> >
> > It would be good to fix this, so the variable is respected.
> 
> I can't reproduce this.  If I load the buggy column-marker.el from
> Bug#4835, set message-log-max to nil, and do M-x column-marker-1, no
> error messages are logged.

You're right.

What I was trying, which does not work, was _binding_ `message-log-max' to nil
in `column-marker-find', which is the function used in the font-lock-keywords
spec.

(defun column-marker-find (col)
  (let ((fn-symb  (intern (format "column-marker-move-to-%d" col))))
    (fset `,fn-symb
          `(lambda (end)
             (let ((start (point))
                   (message-log-max  nil)) ; <<<<<<<<<<<<<
              ...)))
    fn-symb))

I was mistakenly assuming that since `column-marker-find' is the function that
performs the font-lock locating, that that was where the message was ultimately
coming from. I assumed that the message was somehow displayed during
font-locking. I knew it was coming from the display-engine code, but I wasn't
clear on the relation between that code and the font-lock code.

I don't see, now, that there is any place in the code where `message-log-max'
could be `let'-bound to nil to suppress such messages. The display-engine code
that logs the message is probably not governed by the scope of any such
user-code `let' form. Am I right about that? 

IOW, binding the variable for font-locking wouldn't seem to make any difference,
no matter where it is done. Please let me know if I'm misunderstanding this
part. How could one bind it, in the context of font-locking, say, so that it has
an effect?

All I can think of to control this by code would be to define a mode (e.g. a
minor mode) that sets the var to nil on entry and restores it on exit. I don't
see how `let'-binding could control it. But I'd like to understand better.

I think you can close this bug. Sorry for the noise.

However, perhaps it would be possible for such message logging to be condensed,
as we generally do for repeated messages. Instead of blindly logging a message
80 zillion times, we could perhaps just write `[800000000 times]' or some such.
That's what we do for other repeated messages. Would that stop/reduce the severe
performance drain?

Please close the bug if you think there is no hope or no value in trying to
reduce the message-logging noise. Thx.

bug#5164: 23.1; message-log-max ignored by display engine

[Drew Adams]

The display engine writes messages to *Messages* even when
`message-log-max' is nil (see bug #4835). This can reduce performance
considerably in some cases.
 
It would be good to fix this, so the variable is respected.
 
If for some reason it is not feasible to fix this, then please at
least fix the doc, to mention this. Neither the manual nor the doc
string say anything about the display code ignoring this variable.
 
 
 
In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
 of 2009-07-29 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4)'