Re: font-lock-fontify-block

[Stefan Monnier]

>> > IMO, font-lock-fontify-block should have a keybinding.  IME, it's too
>> > important to be left without one.
>> 
>> Wow, I didn't expect that.  I was instead about to ask for details about
>> the mentions of `font-lock-fontify-block' since I view it as a command
>> which "should" be a no-op (barring bugs, obviously).
>> 
>> I'd be quite interested to know more about those existing use cases (they
>> may point to other misgivings of mine, as well).
>
> When I edit code, I sometimes see it mis-fontified when I'm half-way
> through editing a syntactic construct.  Unlike some others, I don't
> expect font-lock to do a 110% perfect job in every situation, and
> prefer a casual M-o M-o to having font-lock definition for a mode
> perfected to a point where it becomes unbearably sluggish.

OK, so your use case is when font-lock is already enabled.
Do you have some general idea of what are the most common reasons for
the temporary mis-fontification?

AFAIK usually misfontifications aren't temporary unless they're linked
to some multiline element, most commonly an unclosed string or comment
and those should get fixed automatically after a short delay.
So is it the case that the cases where you needed `M-o M-o` would
fix themselves after a short delay anyway (I'm OK with keeping such
a command for the case you don't want to wait, I'm just trying to
understand what it is that `M-o M-o` corrects).
Can you think of other cases where `M-o M-o` improved the fontification?

Would you be OK with the idea of deprecating the use of
`font-lock-fontify-block' for the specific case where font-lock is
not enabled?

Also, I suspect that for your use case, we could have a general
"refresh" command, which just calls `font-lock-flush`, which would not
depend on the ill-defined notion of "block" (and wouldn't mess with the
mark).


        Stefan