bug#4835: 23.1; Improper `Invalid face reference' messages. Performance degraded.

[Drew Adams]

> > 2. The code I had seems nevertheless to "work", in the sense that it
> > does what I expect (highlights the column). Except that it 
> > logs those messages and the performance is terrible.
> 
> I suspect this is because parts of font-lock do this:
>   (if (stringp matcher)
>       (re-search-forward matcher end t)
>    (funcall matcher end)))
> 
> while other parts do this:
>   (font-lock-eval-keywords (if (fboundp keywords)
>                                (funcall keywords)
>                              (eval keywords)))))
> 
> If `matcher' is a lambda expression, the first will work as expected,
> because you can pass a lambda to funcall.  But the second will do the
> wrong thing.
> 
> We should probably fix the code to check for and disallow lambda
> expressions (and the docs), assuming not too much external code is
> relying on the unintended behavior.

This part of the thread is only tangentially related to the bug report, but
anyway:

Why is it necessary to restrict the function to a symbol - why disallow lambda
forms? IOW, why can't we use (functionp keywords) instead of (fboundp keywords)?

After all, we're just calling `funcall', and all `funcall' requires of its
function arg is that it be `functionp'. Is there a real reason for the current
restriction to symbols?

Besides, as I noted in a previous mail, the font-lock code itself apparently
uses a lambda form in this way.

Just asking. I don't claim to understand the font-lock code.