Stefan Monnier wrote:
Can you explain the change?
I really don't like the
(defun turn-on-font-lock-as-appropriate ()
(let (font-lock-set-defaults)
(turn-on-font-lock-if-enabled)))
since it may cause font-lock-keywords to be reset from font-lock-defaults,
thus throwing away keywords added via font-lock-add-keywords since.
I believe that I want to make one change to my original patch, namely
to add `check-buffers' rather than `buffes' to find-file-hook. So I
will explain things using this additional change.
The problem that binding font-lock-defaults to nil tries to solve is
that (with org-mode's yesterday's version), after font-lock was turned
on in outline-mode, I could not get it correct for org-mode by
disabling and enabling font-lock-mode, font-lock just kept using
outline-mode's font-lock settings. Note that some mode hooks
(comint-mode-hook, for instance) enable font-lock by default. So it
would seem that a mode derived from comint-mode in a non-standard way
_already_ would have had org-mode type problems _before_ my patch to
easy-mmode.
`turn-on-font-lock-as-appropriate' would only be used by
`define-global-minor-mode'. What I want to do is the following. When
`after-change-major-mode' enables font-lock, it records what mode it
did it for in easy-mmode-stored-mode. It does not remove any buffers
from the list to check. When then either find-file-hook or
post-command-hook run, they do remove buffers, but, if font-lock is
already enabled, they first check easy-mmode-stored-mode. If it is
non-nil and different from `major-mode', we know that
after-change-major-mode ran to soon. (Maybe we should also print an
error message in this case, which my current patch does not). We
_must_ correct this. (I do not know how to do that without setting
font-lock-defaults to nil.) If it is nil and font-lock is already
enabled, we know that something else set font-lock, maybe a major mode
body or a user hook. Here, we do not know whether or not it was set
for the right mode. To be sure, we undo the setting anyway and do
things over to be sure that it is set for the right mode.
Sincerely,
Luc.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
