Re: org-mode and mode hooks.

[Richard Stallman]

    I believe that we plan to eventually make all modes run
    `after-change-major-mode-hook', usually as a byproduct of making them
    run their mode hook with `run-mode-hooks'.

If there are any major modes that fail to use run-mode-hooks, we want
to fix them now.  It would be good for someone to look for them.

However, users also have major modes, and we probably cannot expect
all of them to be changed for many years.  So it will not be possible
to absolutely rely on all major modes to run after-change-major-mode-hook
at the end.  Features that depend on this will fail to work in those
user-defined major modes that have not been updated.

In some cases that will not be a real problem.  When it is ok to say,
"Your major mode has a bug and needs to be corrected," we can say it.
For instance, if a global minor mode doesn't turn on in the user's
major mode because of this, we can respond that way.

However, when a feature really needs to be reliable, it should not use
after-change-major-mode-hook now or for the next few years.  I will
document that in the manual.

    I do not know whether there are a lot of derived modes that do not
    follow the convention.  The most satisfactory solution would obviously
    be to make them all follow the conventions.  If this would be
    unrealistic, possibilities include to come up with a better fallback
    alternative or to simply revert my change.

If the change provides advantages, we have no reason to revert it.
What is the worst thing that can happen when a derived mode fails to
run after-change-major-mode-hook?  Only that it won't enable certain
global minor modes.  If that bothers the user, he can fix his derived
mode to follow the latest conventions.

However, if we can easily make global minor modes work more reliably,
we may as well do so.  Perhaps by using find-file-hook *as well as*
after-change-major-mode-hook.  Why not?