Re: master 2399541: Remove font-lock toggle from font-lock-update

[Stefan Monnier]

>>> One thing I'm not entirely sure is whether the second case is (and
>>> font-lock-mode (not font-lock-keywords)) or (and font-lock-mode (not
>>> font-lock-fontified)), but my guess is that font-lock-fontified is an
>>> internal variable and that it is safer to use font-lock-keywords here.
>>
>> I'm not entirely sure what is the best way to detect this middle-point
>> either.  The code that decides whether to activate the font-lock machinery
>> calls `font-lock-specified-p` for that, but maybe there are corner cases
>> where the machinery can be activated even when `font-lock-specified-p`
>> returns nil?  Similarly, I'm not sure if `font-lock-fontified` is always
>> non-nil when the font-lock machinery is activated and always nil when it
>> isn't.
>>
>> IOW, someone needs to look carefully at the code to find out (and
>> presumably then document the result e.g. by adding a function that returns
>> this info, or with comments, or by adding a variable which keeps track of
>> this info or ...).
>>
>
> I guess that Someone^TM is me? ;-)  I'll have a look.

BTW, this relates to the distinction between "font-lock-mode, the minor
mode that control whether there is highlighting or not" and
"font-lock-mode, the most common way to apply highlighting when
requested".

Admittedly, it seems the only user of `font-lock-function` (the core
variable that allows taking advantage of this distinction to provide
a different machinery) is `ert.el` which just uses in a marginal way
that could probably be replace by the use of `font-lock-hook` or
something like that.

>>>>> +Otherwise, with prefix ARG, toggle Font Lock mode."
>>>>
>>>> Is this behavior useful?
>>>
>>> I think it is, yes, and I think it makes sense to use the prefix argument
>>> for that.  M-x font-lock-mode does not always produce the expected
>>> effect, which can be puzzling, so having a way to "do what I mean" in
>>> a command is useful.
>>
>> Could you describe what you mean by "does not always produce the expected
>> effect" here?  [ And maybe how the prefix ARG to `font-lock-dwim` avoids
>> those problems?  ]
>>
> By "does not always produce the expected effect", I mean for example that
> M-x font-lock-mode in a text-mode or fundamental-mode buffer does not
> remove then fontification from a piece of code that was killed-yanked from

I see.  IIUC, that's unrelated to the:

    Otherwise, with prefix ARG, toggle Font Lock mode

part of the command's behavior, right?


        Stefan