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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru,  acm@muc.de,  emacs-devel@gnu.org
> Date: Thu, 14 Nov 2019 16:29:38 -0500
> 
> >> 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.
> 
> IIUC this can't be fixed in font-lock or jit-lock.

Why not?

> It can only be fixed "upstream" (e.g. in repos-count-screen-lines)
> or "downstream" (in the particular major mode's rules).

I believe my original suggestion was to fix this in CC Mode, but you
seemed to disagree.  So now you do agree with that?

> > So we are going to do such changes in every application that calls
> > vertical-motion, directly or indirectly?
> 
> I'd phrase it as "this would need to be done in any narrowing
> which changes point-min and internally can trigger jit-lock".

That's any number of places out there, and I don't see how could they
be identified.

> The fix should not be "where we can do vertical-motion (and friends)"
> but "where we narrow (and later trigger jit-lock)".  Whether that means
> "fix their callers as well" depends on what it is that owns the "their
> callers": yes it would be in the functions that call (directly or not)
> `vertical-motion` (and friends) but in the functions that call
> those functions.

Sorry, I don't think this is practical.  I think fixing this in CC
Mode is a much better alternative.

> In any case, changing the narrow-to-region so it doesn't change
> point-min is the right fix.  Adding a call to `jit-lock-fontify-now` is
> another but worse way to fix it.

I don't think any of these two ways were proposed as patches, so I
don't think I understand well enough what are those changes you prefer
here.

> Adding that call should be harmless and could be beneficial for
> performance, but I personally wouldn't do it (it can also be harmful
> for performance in the case where the text has already been jit-locked
> in which case it won't do anything but will still take a bit of time to
> do it).

What is "that call" in this context?