bug#71345: Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: jdtsmith@gmail.com,  71345@debbugs.gnu.org,  dmitry@gutov.dev
> Date: Wed, 05 Jun 2024 12:59:08 -0400
> 
> >> But the highlighting is done "once and for all" (at least until the next
> >> command), so if you want it to be different in different windows (to
> >> reflect the different values of `point` in those windows) you'll need
> >> overlays with the `window` property because the highlighting will not be
> >> re-done in the middle of redisplay when we go from one window to another.
> >
> > In that case, we are in trouble anyway, because the "once and for all"
> > highlighting could be (by sheer luck) be done by display code that
> > doesn't run as part of redisplay, but as part of something else, like
> > vertical-motion.
> 
> I can't see why that would be a problem.
> 
> The highlighting code run from `jit-lock` will usually not be able to
> use `point` (or `window-point`) directly.  Instead, that highlighter
> will need to keep track of the windows' points elsewhere "manually" via
> hooks like `post-command-hook` or `pre-redisplay-functions` and then
> rely on that info when performing the highlighting.

You say you don't see a problem, but then describe a solution for a
problem you don't see? ;-)

Yes, if the code run from jit-lock will use some private variable
instead of point, it can get away, but such a code will need to be
written in an extremely disciplined manner, like nothing else in Emacs
(except, perhaps, the inner parts of redisplay code in C), because
what is more natural than call functions and APIs under the assumption
that point is where it's expected to be?