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

[Gregory Heytings]

> That's the wrong question, since my beef is about the definition of what 
> the function should do, as opposed to how it's implemented.

I think the simplest way to express what the function should do is: if 
something is wrong with the fontification, fix it.  (And with a prefix 
argument, toggle fontification.)

That's basically what Eli used font-lock-fontify-block for, for instance. 
Someone else said something like "I did not know that 
font-lock-fontify-block exists, when the fontification is wrong, I just 
turn font-lock-mode off and on".

> [ Tho maybe I'd prefer if it used `font-lock-flush` or 
> `font-lock-ensure`.  ]

Yes, but alas that doesn't work e.g. when yanking a font-locked string 
into a text-mode buffer.

> > > I'd much prefer a longer `font-lock-fontify-diwm` which tries to 
> > > reproduce more or less the same behavior as your favorite, but by 
> > > explicitly testing the different circumstances you care about.
> >
> > Could you perhaps give an example of such a circumstance and its 
> > corresponding action?
>
> The main "circumstances" that matter are whether the font-lock machinery 
> is activated and whether font-lock-mode is nil or not.

Are these two separate conditions?  Or does font-lock-mode t imply that 
the font-lock machinery is activated?  (Apart from the case where someone 
would do (progn (font-lock-mode -1) (setq font-lock-mode t)) of course.)

> Currently, I've heard mention of two use cases for 
> font-lock-fontify-block:
>
>  ;; - Correct misfontification when fontification is highly context-dependent
>  ;;  and has a bug (typically associated with multiline constructs).
>  ;;  `font-lock-flush` should work as well in that case.
>  ;; - Removing fontification, e.g. when yanking font-locked strings into
>  ;;  a text-mode buffer.  Not sure if the intention would be to generalize
>  ;;  this to all buffers with a nil `font-lock-keywords` or also to buffers
>  ;;  where font-lock-mode is disabled.

There is another use case I think, which is close to your first use case, 
and is perhaps the most common one: the fontification is not what you 
expect (say, you're inside a function and the fontification indicates 
you're inside a comment), and you are not sure whether it's because the 
fontification has not yet been updated, or because you indeed forgot to 
close a comment.  A refontifcation is useful in that case, too.

Another similar case is when you know that the fontification should change 
and do not want to wait for the refontification to take place (say, you 
open a comment, and want immediately see the effect).

In those case font-lock-flush should work well, too.

> Maybe the docstring should describe just those behaviors, and the 
> implementation could then implement them explicitly, rather than have 
> that grow accidentally as a result of the implementation.

Is a KISS approach not better?  Could it do something wrong?  What would 
be the benefit of identifying use cases one by one and adding them to a 
(presumably much more complex) function?

I attach an updated patch; it occurred to me that with outline-mode and 
friends, "far away from point" might not be enough to cover the window.

0001-Improve-font-lock-update-and-rename-it-to-font-lock-.patch
Description: Text Data