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

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

> 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 ...).

>>> +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?  ]


        Stefan