RE: feature request: text property to prevent font-locking

[Drew Adams]

> font-lock-default-unfontify-region leaves alone any "alternative"
> (defined in char-property-alias-alist) of the `face' text property.

"Leaves alone?"  It think it does the opposite: it removes its
highlighting: it treats the alternative property like it treats
`face' (and `font-lock-face').  But perhaps I misunderstand you.

> In particular, this is how the font-lock-face text property works.

Yes, and thanks for pointing that out, as it is not obvious how
`font-lock-face' is handled by `font-lock-default-unfontify-region'.

But again, IIUC, it does not "leave alone" `font-lock-face'd text.
It does just the opposite: it unfontifies it.

That's even worse wrt unhighlighting than not doing anything.
If you do nothing, then text that you have applied `face' to
will at least appear highlighted when you turn off `font-lock-mode'.

By using your suggested "leave alone" approach, you give font-lock
control over not only highlighting but unhighlighting, so your
ad hoc highlighting will never show, whether font-lock is on or off.

> Now, on the one hand, keyword fontification does not override
> "alternatives" (except if the highlight pattern has an `override'
> flag). This is because text-property-not-all recognizes them and
> thus prevents font-lock-apply-highlight from adding a value for
> the `face' property.

Yes.  That is the point, AFAICT, of `font-lock-face': to let you
give font-lock control over some ad hoc highlighting.  And yes,
you can use an "alternative" property for the same thing.

> On the other hand, some experimenting suggests that syntactic
> fontification does override those "alternatives".

Yes, I noticed that too.

But beyond that: What you are describing is just the control that
font-lock has over highlighting, and how one can give it control
over additional, non-`font-lock-keywords' highlighting by using
`font-lock-face' (or another property besides `face', designated
as a `face' "alternative").

What I am talking about is the opposite: Not giving font-lock
control over additional, ad hoc highlighting, but taking font-lock
control away, for given ad hoc highlighting.  I don't want turning
font-lock on or off to affect the given highlighting at all.

That's the point.  It's not that I'm looking for a way to let
font-lock control some non-`font-lock-keywords' highlighting.
That we can do already, using property `font-lock-face'.

(And my guess is that the fact that this is the only feature for
ad hoc highlighting that is compatible with font-lock is a reason
that we have seen an expansion of the use of `font-lock-face'.
IOW, if you want some ad hoc highlighting, you are currently
pretty much obliged to give font-lock control over it, by using
that approach.)

> > I want to apply some other text property to the highlighted text,
> > to tell font-lock not to fiddle with it ("hands off this text").
> 
> Remove it from the value of `font-lock-extra-managed-props'.

Remove what?  The highlighting property?  It's `face', which is
already not in `font-lock-extra-managed-props'.  The default value
of `font-lock-extra-managed-props' is nil (or it should be; and
hopefully it will be again, after bug #18343 gets fixed).

That's the point: font-lock should not "own" `face'.  And it
pretty much does currently.  Whether it did in the beginning I
don't know, but I kinda doubt it.  Property `face' was not
invented for font-lock, AFAIK.  Font-lock is one application of
the feature of faces; nothing more.  But it does not play well
with other uses of that feature - it is a sandbox bully.

> tl; dr: Existing facilities reduce the problem to clashes with
> syntactic fontification.

That's your point, not mine.  But yes, the feature I proposed
lets you protect given text also from overriding by syntactic
fontification.