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

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Thu, 14 Nov 2019 13:51:05 -0500
> 
> >> 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.

I'm also okay with fixing it in font-lock or jit-lock.  But doing that
inside reposition.el makes no sense to me.

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

So we are going to do such changes in every application that calls
vertical-motion, directly or indirectly?  And what about
posn-at-point, or pos-visible-in-window-p, or any other API that uses
the display code internally? are we going to fix their callers as
well?  That really makes no sense, so I very much hope I somehow
grossly misunderstand what you are suggesting as a fix.

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

So you are saying that we should enlarge jit-lock-chunk-size to
most-positive-fixnum?  I don't think so.