bug#34764: prettify-symbols-mode pollutes font-lock-extra-keywords

[Drew Adams <drew.adams@oracle.com>]

> > No, in fact I wasn't aware of `char-property-alias-alist'. ;-)
> >
> > I just meant in some way to try to have a library-specific
> > property control or replace a general property.  I don't
> > have in mind a general mechanism for doing that.
> 
> Font font-lock-extra-managed-props, at least, char-property-alias-alist
> seems perfect: you can declare my-abc to be an alias of abc, add my-abc
> to char-property-alias-alist when the minor mode gets activated, remove
> it when it gets deactivated, and as a bonus when clearing fontification
> font-lock will only clear the instances of abc that it applied itself.
> Very neat.

Yes, font-lock is a special case, because it already
deals in such a general way with a _list_ of properties,
"managing" them similarly.

Beyond that, one's code needs, one way or another, to
ensure that a library-specific property can have the
effect of the general, global one.  That's not built-in,
AFAIK.
_________

There is another case, which I forgot to mention, where
there is something general and built-in, but not
only for properties.  That's `buffer-invisibility-spec'.

By that I mean that you can add your own entries to
that spec, and you can remove them.  Other entries are
not affected.  (There are even specific functions to
add and remove.)

Something similar happens with hooks.

These are all places/constructs designed to be
modified by more than one library for more than one
purpose.  They are all, in a general sense, "hooks".

Another example, in the realm of properties, is the
exceptional way we treat property `face': code generally
handles both the case where the property value is a
single symbol (e.g. `lazy-highlight') and the case where
the value is a list of such.  Again: easy to add and
remove, without affecting what might be there from other
code.

A property whose value is expected/allowed to be a list
of values, each of which can determine the behavior,
is more flexible.

Whether this could or should be generalized, I don't
know.  But it sure is easier to keep the effects of
some code (e.g. a mode) separate in the cases where
we've planned ahead for a list of behavior-modifying
entries rather than just a single such.