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

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

> > The idea of the feature is that a face property that
> > contains text properties as (pseudo) face attributes
> > would produce the same effect as applying those text
> > properties to the text.  But those text properties
> > would not in fact be applied to the text - they would
> > remain encapsulated in the value of the applied face
> > property (`face', `font-lock-face', or `mouse-face').
> 
> As I explained, the display engine, which is the part that implements
> the faces, will be unable to do anything with attributes that don't
> affect display.

Yes, you explained that.  Thanks.

Does that mean that such code could not invoke _other_ code
that _would_ be able to do something with those text properties
(that masquerade in a face spec as face attributes)?

> And the implementation of the features which do need
> to pay attention to such attributes is entirely unrelated to faces.
> So I don't understand why you want this to be attributes of faces.

I think by now you should understand why I proposed the
feature - its use.  I've made that pretty clear.

You are free to think that it's a useless feature, of course,
and you are free to think that it might be useful but is not
feasible to implement.

> Moreover, you consistently mention the display engine as the main part
> of this proposal.

See my replies to your (repeated) diatribes about my
mistakenly referring to the "display engine".  I was only
trying to describe the desired feature, not to speak to
which code really would, could, or should implement it.
Mille excuses for having naively invoked the terms
"redisplay" and "display engine".

> But features that don't affect display cannot be
> usefully built on top of the display code, because the display code is
> designed to run and examine text only when and where there's likely to
> be changes in buffer text that will affect the display.

I suppose it is natural that you immediately go down the
rabbit hole of thinking in terms of implementation.  And
that is no doubt helpful to the discourse overall.

But it doen't really jibe with your claim not to understand
what I mean by the feature itself and its raison d'etre.
So far, anyway, I haven't noticed anyone else who has not
gotten the point of the feature.  (It is true that we've
heard from only two other readers so far.)

> By contrast,
> the non display-related properties need to be processed regardless of
> any changes that could affect display.  Do you see a conflict here
> between the goals and the proposed design?

I didn't propose any design.  And you've already made clear
that you do not understand the goals.  But I guess that
doesn't stop you from seeing such a conflict.

One more time: I do not pretend to know how this feature
would, could, or should be implemented.