Major modes should follow the conventions for
major modes rigorously. But, in addition, they should not enable Font
Lock in any way, directly or indirectly (other than through the
define-global-minor-mode machinery), and they also should not call
font-lock-add-keywords directly or indirectly, even if this does not
enable Font Lock.
I just looked for all the calls to font-lock-add-keywords in Emacs.
In no case does any major mode call font-lock-add-keywords directly,
or even fairly directly. But it seems plausible to me that mode hook
functions might call functions that call font-lock-add-keywords.
Would that be a problem?
comint-mode and interactive-sql-mode both enable
Font Lock (the latter via sql-product-font-lock), creating problems
for modes derived from them.
I think it would be more consistent, nowadays, to turn that off.
Anyway, how about if we change define-minor-mode so that it generates
the code to record which major mode enabled it?
The very vast majority of minor modes have no reason whatsoever to do
this.
Does that matter?
If only a few of them need to do this, perhaps it is better to do
this automatically in all the minor modes (even though it is
unnecessary in most of them) than to make users do it manually
and risk bugs.
The only known example (and
hopefully the only example, period) is Font Lock mode.
If these complexities apply only to Font Lock mode,
perhaps we don't need to document them in the doc string
of define-global-minor-mode.
I will propose a new patch to easy-mmode that does _not_ use the new
variable MODE-stored-mode. It will say that dis- and then re-enabling
the minor mode should correctly set up the minor mode for the current
major mode.
Ok, but...
The only trouble with that is that this condition does
not apply to Font Lock.
if the problem exists only for Font Lock mode, and your proposed
solution does not solve it for Font Lock mode, what problem is
this solution solving?
The problem is that if you call these functions with `nil' for MODE,
this sets up Font Lock for the current major mode, which could be an
ancestor mode (it calls font-lock-set-defaults).
I don't understand. How can the current major mode "be" an ancestor
mode? Do you mean that the font-lock settings came from an ancestor
mode?
But if font-lock-add-keywords was called with `nil' for MODE,
my patch will undo the adding of the keyword.
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.
It's possible this would do something wrong in certain
other cases, but would it do the right thing in these cases?
Note that even after this patch, there is one potentially troublesome
case left. It concerns the case of a major mode that gets enabled by
a timer or process for a non-file visiting buffer.
Would you please explain what problem would happen in this case?
It is hard to understand your arguments about proposed solutions
when you haven't said what the problem is.
(Even in this case
it is only likely to occur for major modes that do not follow the new
conventions.)
In that case, maybe it is a fine solution to tell people to fix their
major modes. Why go to a lot of trouble about broken major modes?
The trouble with doing that for Font Lock, given its current code, is
what happens if after-change-major-mode never ran Font Lock, and Font
Lock is nevertheless enabled. Then it was set by something else.
What kind of something else could it be?
One possibility is that the major mode itself turned on font-lock
mode. You've said that there's a problem when a major mode turns on
font-lock mode.
Aside from that, what other case could do that?
Anyway, please explain why you think it is difficult for turning font
lock off and on again to give the right results. Can my proposed
change to font-lock-add-keywords work? If not, why not?
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
