[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 7362554: Widen around c-font-lock-fontify-region. This fixes

From: Stefan Monnier
Subject: Re: master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049.
Date: Thu, 14 Nov 2019 13:51:05 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> So, your earlier patch which added a call to `font-lock-ensure` was
>> "more or less right", except that it should have used
>> `jit-lock-ensure` (currently called `jit-lock-fontify-now`) and
>> could have a comment explaining that vertical-motion will trigger
>> jit-lock anyway so it's better to do it once beforehand on the whole
>> region, not only so it can be done outside of the narrowing but also
>> so it can be done more efficiently than one jit-lock-chunk-size at a
>> time.
> I'd like to solve this in CC mode instead, because the problem is there.

I think the problem is wider than CC-mode.  Maybe CC-mode is more
susceptible to it or maybe it's just an accident that this was reported
for CC-mode, but running font-lock (and syntax-propertize) within
narrowing tends to be fiddly.

> Fontifying arbitrary portions of the buffer to indirectly
> avoid triggering the problem in CC mode sounds not TRT to me.

`vertical-motion` *will* call `jit-lock-fontify-now` on all those buffer
positions in any case, so while it is extra code I'd rather we don't need
to write, it shouldn't have a negative impact on performance, quite the

> In particular, what if the POINT-MIN..END chunk is still too large to
> fontify in one go?

AFAIK all uses of jit-lock are more efficient if they get fewer larger
chunks than more smaller chunks.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]