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

[Stefan Monnier]

>> >> Because a given buffer can have several (window-)points,
>> >> position-dependent highlighting will ideally want to be added via
>> >> (window-specific) overlays rather than text-properties.
>> >
>> > Not sure I understand how this remark is relevant to the issue
>> > discussed here, but let me just point out that when redisplay starts
>> > working on a window, it temporarily moves point to the window-point
>> > position.  So position-dependent highlighting will behave in each
>> > window according to its window-point, which I think is what's expected
>> > here?
>> 
>> 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.


        Stefan