Re: org-mode and mode hooks.

[Stefan Monnier <monnier@iro.umontreal.ca>]

>    Could be, but your change does not try to fix it, instead it documents the
>    part of the misbehavior we happen to know about, thus legitimizing the use,
>    rather than discouraging it.

> But your previous text, even when read as intended:

>    whereas I meant it to mean:

>       Use a non-@code{nil} @var{mode} argument only when you use
>       @code{font-lock-add-keywords} or @code{font-lock-remove-keywords} in your
>       @file{.emacs} file.

> legitimizes the use, since it says that it is OK to use it in your
> .emacs, and that is probably the main use.  It does not tell what
> difference it makes if you use a nil or non-nil argument from your
> .emacs.

>> The misleading text in question made me lose a lot of time.

>    In what way, specifically?  Which hook did you try?

> It was completely impossible to figure out what a nil MODE arg was
> _trying_ to do.

Don't know about the TeXinfo doc, but the docstring is pretty clear:

   MODE should be a symbol, the major mode command name, such as `c-mode'
   or nil.  If nil, highlighting keywords are added for the current buffer.

> You could not look at the actual behavior, because
> before my patches the behavior with a nil MODE argument made no sense.

Huh?  I've used it for many years with a nil argument and it worked
just fine.  You know very well that the problem you fixed only occurred in
some particular cases.

> If Font Lock was for some reason enabled for the wrong mode, it was
> impossible to correct reliably.

That unrelated to the TeXinfo doc.  You're here arguing for your patch,
which is a waste of time, since it's installed and nobody objected to it.

> The docs clearly seemed to suggest that a nil argument tried to enable the
> keywords for MODE only and not for derived modes,

Then the docs obviously need to be fixed, since there is no nil MODE.

>    As mention, I'd like to semi-obsolete it, so I'd rather not document
>    it further: use at your own risk.
> As long as it is mentioned for possible use in .emacs, it is not
> semi-obsolete.

No: as long as it's mentioned, it's not *obsolete*.  That's why I say
semi-obsolete.


        Stefan