> 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 [EMAIL PROTECTED] @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
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
