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

[Eli Zaretskii <eliz@gnu.org>]

> From: JD Smith <jdtsmith@gmail.com>
> Cc: monnier@iro.umontreal.ca, 71345@debbugs.gnu.org
> Date: Wed, 5 Jun 2024 10:02:23 -0400
> 
>  In general, yes.  In my case having the scope be per-buffer not per window makes the most sense in
>  terms of
> 
>  the functionality.
> 
>  Given the feature of redisplay I just mentioned, you will actually get
> 
>  a per-window functionality, at least as far as the position of point
> 
>  is concerned.
> 
> Not in my case, since I am discriminating between point in the selected window and other windows showing the
> same buffer, such that switching windows = changing point. Since much of the work in my mode is not
> position-dependent but depends on text content, updating face is the natural thing.  

Sorry, I don't think I understand you.  But if the fact that redisplay
moves point to window-point doesn't bother me, we can drop this issue.

> Thinking more about what makes font-lock “special” as a jit-lock backend, it is exactly this: font-lock claims
> exclusive ownership of `face'.  Solutions I can see:
> 
> 1 Make font-lock a good citizen by using its own alias for face. 
> 2 Give other jit-lock backends which may alter face and potentially conflict with font-lock the ability to specify
>  to jit-lock “if you re-run font lock on a region, re-run me too after that.”

I don't understand.  The solution to this dilemma is well known: Lisp
programs that want to control faces without turning off font-lock mode
should set font-lock-face property, instead of the face property.  Why
do you need to find another solution?