martin rudalics <[EMAIL PROTECTED]> writes:
>> (set (make-local-variable 'font-lock-keywords)
>> ! (font-lock-eval-keywords (or keywords font-lock-keywords)))
>
> Wouldn't this mean that old keywords survive a major-mode change?
> What about the companions in `font-lock-defaults'? In general I
> think all those should survive iff they have been hacked before.
It's saner to treat font-lock-keywords as an internal variable, so
that anything that wants to change font lock highlighting should use
font-lock-defaults or font-lock-add/remove-keywords. This is already
implicitly the case: according to the font-lock-keywords docstring,
Normally the [value of font-lock-keywords] would come from
`font-lock-defaults' ... You can also alter it by calling
`font-lock-add-keywords' or `font-lock-remove-keywords'...
The proximate cause for the problem seen by Francesco Potorti is that
font-lock-set-defaults recomputes the value of font-lock-keywords.
One easy way to avoid this is, as mentioned by Francesco Potorti, to
change font-lock-defaults; another way (since font-lock-add-keywords
runs font-lock-set-defaults) is:
Local variables:
eval: (font-lock-add-keywords nil '("^asdf"))
end:
Since setting font-lock-keywords in file local variables is something
of a hack in the first place, I don't think this should delay the
Emacs 22.1 release.
As for making font-lock-keywords and font-lock-defaults survive a
major-mode change if they have been hacked on before, I think that is
a bad idea, because it introduces an unnecessary complication. Any
"external" Lisp code that hacks font-lock-keywords/defaults and wants
it to persist through major-mode changes can easily arrange to
re-apply its changes.
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
