Re: org-mode and mode hooks.

[Luc Teirlinck <teirllm@dms.auburn.edu>]

Richard Stallman wrote:

   It sounds like you are saying that with your patch, Font Lock mode
   still works wrong.

Essentially, yes.  It can only work correctly if all major modes not
only adhere strictly to our new Emacs 22 conventions, but in addition
carefully avoid anything that enables font-lock (other than
through the define-global-minor-mode machinery) or that calls
font-lock-{add,remove}-keywords, directly or indirectly.

   If so, that means this fix doesn't fix things.
   We need to figure out what to do about Font Lock mode.

The _one_ big problem is that dis- and then re-enabling Font Lock is
not sufficient to reliably adapt Font Lock for the current major mode
if it has already been configured earlier in an ancestor mode.  (In
fact there seems to be currently _no way whatsoever_ to reliably
correct a prior configuration for an ancestor mode.)  Without this
problem Font Lock does _not_ need to keep track of the major mode.  In
fact, even major modes that do not adhere to the new conventions no
longer would present problems.

I believe that it is definitely theoretically possible to redesign
Font Lock in such a way that dis- and re-enabling it would configure
reliably for the current major mode, even with prior misconfiguration.
This would seem highly desirable.  But it seems non-trivial and
requires a much better knowledge of all the intricate details of Font
Lock than I personally have.  So somebody else would have to do it.

   If so, that means this fix doesn't fix things.
   We need to figure out what to do about Font Lock mode.

   Can you explain the problem with Font Lock mode
   that remains after your proposed patch?

Stefan knows the Font Lock code better than I do.  But if I understand
things correctly (otherwise, Stefan can correct me) the problem is this
excerpt from `(elisp)Search-based Fontification', talking about
font-lock-{add,remove}-keywords:

  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.

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).  This problem also
occurs if the ancestor mode enables font-lock-mode.  But the problem
with font-lock-add-keywords with `nil' for MODE is _way worse_.  If
all that happened was that font-lock-mode was enabled too soon, but
without font-lock-{add,remove}-keywords being ever called, then I
believe that my patch will reliably correct for the actual final major
mode.  But if font-lock-add-keywords was called with `nil' for MODE,
my patch will undo the adding of the keyword.  However, a `nil'
argument means that the adding should be independent of the MODE, so
we are in trouble.

The only way out of this trouble, without non-trivial changes to Font
Lock, is a convention that major modes should not directly or
indirectly call font-lock-{add,remove}-keywords.  I do not even know
whether that convention would be reasonable.  But even if we adopt
that convention, we should hunt for modes that do not follow it and
correct them, hence the error message.

Sincerely,

Luc.