Richard Stallman wrote:
But it seems plausible to me that mode hook
functions might call functions that call font-lock-add-keywords.
Would that be a problem?
I am not the Font Lock maintainer and I do not know every aspect of
Font Lock. But, in as far as I understand things, if they pass a
non-nil MODE argument everything is OK in as far as the problems we
are discussing. Major modes, hook functions, or anything else can call
font-lock-add-keywords with a non-nil MODE argument without creating
any problems of the type we are discussing. But if anything, mode
hooks, whatever, directly or indirectly calls font-lock-add-keywords
with a nil MODE argument at any time during a major mode function,
trouble could potentially result.
Suppose we make font-lock-add-keywords with nil for MODE
record its argument in some permanent buffer-local variable.
Then changing the major mode and reenabling font-lock
would use the same keywords previously added.
That would also change the current behavior when changing a major mode
interactively. Currently, it gets rid of these keywords. When
changing modes interactively, the situation is thousands of times more
likely to occur than when changing major modes inside a derived mode.
Stefan does not seem to consider getting rid of these keywords to be
a problem when changing modes interactively, although he does consider
it a problem when it happens in a derived mode. Maybe there should be
such a variable but it should not be permanent local. When modes
change inside a derived mode, kill-all-local-variables is not called.
It is only called when the very first mode function is called.
An alternative would be to get rid of the mysterious "subtle problems
due to the details of the implementation" mentioned in the following
quote from `(elisp)Search-based Fontification':
*Warning:* Only use a non-`nil' MODE argument when you use
`font-lock-add-keywords' or `font-lock-remove-keywords' in your
`.emacs' file. When you use these functions from a Lisp program (such
as a minor mode), we recommend that you use `nil' for MODE (and place
the call on a hook) to avoid subtle problems due to the details of the
implementation.
Then we could say instead that a non-nil MODE argument should only be
used in such a way that it could never be directly or indirectly
called from a major mode.
Sincerely,
Luc.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
