emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: org-mode and mode hooks.


From: Richard Stallman
Subject: Re: org-mode and mode hooks.
Date: Tue, 31 May 2005 00:18:14 -0400

    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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]