[Bug: 21.5-b27] font-lock-fontify-* / infinite loop

[Stephen J. Turnbull]

Wulf, can you elicit the bug and give us the value of
message-font-lock-keywords?  Rationale follows.

Aidan Kehoe writes:

 > It seems the lambda is too deep for the automatic compilation that happens
 > for lambda forms to kick in.

??  AFAIK lambda forms are supposed to get compiled when they appear
in a functional context, and not otherwise.  The arguments to defvar
are not a functional context, so you'd need to explicitly
byte-compile:

(defvar matcher (eval-when-compile (byte-compile (lambda (limit) 42))))

 > in, since this function will be called from font-lock, quite possibly with
 > funcall, which, as we saw, can’t handle an uncompiled lambda form. 

funcall (apply, eval) have no such problems.  Viz:

(funcall (lambda (x) x) "Do it to it!")
=> "Do it to it!"

Nor is it a problem in my XEmacs where *all* of the matchers are
uncompiled lambda forms.  This is due to the fact that in XEmacs
at startup (featurep 'bytecomp) => nil, although (functionp
'byte-compile) => t (it's autoloaded).  So a require to bytecomp is
needed for that definition to function as desired.

However, loading bytecomp and executing that defvar does *not* cause
me any problems, I still can't reproduce Wulf's errors with the
definition of message-font-lock-keywords being a mix of compiled and
uncompiled MATCHERs.  Although all of the MATCHERS in the keywords
list are supposed to be tried in order.

The problem is that something is arranging for some lambda form to be
evaluated as a function call:

(funcall 'lambda '(x) 'x)

but I have no idea how that is happening.  The only thing I can thing
of is that somehow the lambda form is getting unwrapped before being
handed to funcall.