Re: font-lock-fontify-block

[Stefan Monnier]

>> 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.
> Probably.  But also when fontification is highly context-dependent, I
> think.

Hmm... I winder what those situations are like.
If/when you can think of examples, that would be very helpful, thanks.

>> 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).
> No, in most cases where I used it, the delay isn't short.  More like
> infinite.

So they really correspond to what I would consider as bugs (some of
which might be known and we don't really know how to fix).

>> 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?
> I only ever use it in that case to _remove_ the faces from text yanked
> from a fontified buffer.  So that's another important use case for
> M-o M-o.

Oh, that never occurred to me.  I generally just "live with it".

>> 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).
>
> I'd have to use it for a while to have an opinion.

For the "yank into text-mode" case, I guess we'd still need to limit the
effect, either via the use of the notion of "block" or by requiring to
select a region.


        Stefan