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.