[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: bug#4835: 23.1; Improper `Invalid face reference' messages. Performance degraded.
Date: Sat, 31 Oct 2009 12:09:37 -0700

> > 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]