Stefan Monnier wrote:
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 i.t
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. You could not look at the actual behavior, because
before my patches the behavior with a nil MODE argument made no sense.
If Font Lock was for some reason enabled for the wrong mode, it was
impossible to correct reliably. The docs clearly seemed to suggest
that a nil argument tried to enable the keywords for MODE only and not
for derived modes, like a non-nil argument does, only without the
mysterious "subtle implementation problems".
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.
Sincerely,
Luc.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
