RE: Idea: Be able to use text properties as face attributes

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

> > for the 'keymap' property.  There's nothing we could do with these
> > attributes during processing of faces by the display engine, except
> > record those attributes somewhere, for future use by their respective
> > features.
> 
> It's worse: the rest of the code can't assume that the display rendering
> has propagated the info from the fact attributes to that
> "to-be-defined-other-place" since redisplay may not have happened yet or
> may not have looked at that part of the buffer yet.

Please reread what I wrote.  I think there has been a
misunderstanding.  This feature has nothing to do with
the display engine per se.  It is only about leveraging
a face's spec to manipulate other text properties at
locations where the face is used.

For that, we would extend face specs to tolerate (ignore)
unknown face attributes (call them pseudo face attributes,
if you like).  And we would support one or more such
attributes that are text-property symbols and their values.

The code that does the supporting (interpreting) of such a
(pseudo) face attribute-that-is-a-text-property is, it is
clear by now (but it was not clear to me initially),
typically _not_ in the display engine.  I think we can
remove "display engine" from the discussion.  I'm sorry
that I (naively) mentioned it when trying to make clear
that _some C code_ would be implicated.

Wherever that code is, it would check for the text
property that it handles (1) first, by looking for a
face property and checking for the text property as one
of the face property's (pseudo) attributes, and (2)
second, IF #1 did not yield the text property, looking
for it directly on the text, as it does today.

The only thing new would be #1: trying to get the text
property first from a face property.  That lets a face
spec override text properties that might already be
applied to the text directly, and it lets a face spec
provide text props that are not yet applied (the general
effect would be as if they had been applied directly).

> This said, Drew's feature doesn't have to require changes all over
> the place.  It might be possible to limit those changes to a few core
> place like Fget_text_property.

I can't speak to where or what code changes would be needed.

I do think, however, that the behavior of `get-text-property'
(and perhaps other functions) should _not_ be changed. 

Instead we should add another function that gives Lisp code
a way to do the checking described above: first, try to get
the text property from within a face property, and then, if
not obtained, use `get-text-property' to try to get it
(directly) - as is the case now.

> This said, I think using face attributes is a bad idea.

Reason?  I can be convinced, but only by reasons.

> Instead, we should consider adding some more general system of
> indirection.  Drew suggests using `face` as a special meta-property.

Yes, I suggest using `face', `font-lock-face', and
`mouse-face' text properties to indirectly specify
other text properties.

I chose face properties not by accident, but because the
feature would let you leverage both (1) existing face
locations (occurrences), and (2) existing commands and
other functions that let users and Lisp easily put a face
property on text in various ways, or change it.

Faces are special in those senses - they constitute
especially handy affordances for manipulating text at
locations that are common or significant for users.

> Current code already supports such a feature but using the name
> `category` and only for overlays (and with some problems linked to the
> fact that modifying that meta-property is done via `get` and `put` which
> are very generic operations used for many other things, so it's
> hard/impossible to detect when those meta-properties are changed, which
> is a fairly serious problem.  The only reason why we don't suffer too
> much from that problem is because those `category` properties aren't
> used very often).
> 
> My proposal for "property planes" is somewhat related to Drew's
> proposal: my "property planes" allow merging various properties into one
> (font-lock can place the (font-lock face) property, and some other
> package can add the (mypkg face) property and they then get merged into
> the one-and-only `face` property), i.e. many-to-one.  Drew wants the
> reverse: adding a single meta-property which then affects several
> other properties, i.e. one-to-many.
> 
> From a more general point of view, the shared desire is to have
> "abstract text properties" from which "actual text properties"
> get computed.

I'd be more interested in your proposal if I had a
better idea of it.  But I suspect that it might be
independent of what I am getting at.

It's true that I'm asking for a way to handle one
or more text properties as a package at different
locations.  But my proposal is purposely aimed at
FACES and where they are applied, for the reasons
given above.  It's not _only_ about packaging text
props together to act on them in an abstract way.

I fear I'm not getting the point across well, but
I'm willing to keep trying if there is a real desire
to understand.

I fear that combining discussion of your proposal
and mine in the same thread will not be helpful -
unless it is a later thread, which can take advantage
of conclusions already drawn about my proposal (e.g.
yay or nay; specific challenges identified, whatever).