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

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

> > > 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)?
> 
> We can invoke (almost) any code we like, but the question is what
> would that other code do with those attributes?  Those attributes,
> like their corresponding text properties, have their effect when the
> corresponding Emacs features are invoked,

And that's the only time the face spec containing those
properties needs to be handled by that other code.

Instead of just looking for the text property that it
handles, as something that belongs to the text char
it checks, it would need to first check that char for
a face property.

And if there is a face property with that text property
embedded in it (as a pseudo face attribute) then whatever
that code would do with the text property it would do
with the text property from the face spec.

That's all.

> like buffer text
> modification for the 'read-only' property or keyboard
> input processing for the 'keymap' property.

Yes, exactly.  The code that checks for and handles a
`read-only' or a `keymap' text property would simply
check for it in two places instead of one: (1) first,
embedded in a face property, if there is one, (2) if
not, directly on the char.

> There's nothing we could do with these
> attributes during processing of faces by the display engine,

Yes, that's been clear for a while now.  You were thrown
off in that direction by my referring to "display engine"
and "redisplay" out of ignorance of where in the C code
this or that property is handled.

The point is that _wherever_ a given text property is
handled in the code, that code would need to take a
larger view to check for the property.  It would not
look only for the property directly on the text; it
would look also (and first) for that property as
embedded in a face property (`face', `font-lock-face',
or  `mouse-face').

> Text properties are precisely a way to record such
> information, but you don't want to use text properties in this case.

I want to use a _face_ text property to record them.
So yes, I do want to use a text property: one of
the properties `face', `font-lock-face', and 
`mouse-face'.  And I want to (be able to) record
the values of other text properties _within the
value of the face property_.

> So some other means of recording the information will
> have to be invented.

No.  Not in my view.  They would be recorded in a face
property.  No other recording needed.

> But since those means will most probably be very similar to
> text properties, at least implementation-wise, what would be the point
> of inventing that?

No such invention is needed, in my view.

> > 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.
> 
> Sorry, I don't understand.  My questions and my confusion are real, so
> please bear with me and don't assume I'm repeatedly asking the same
> questions for argument's sake.  I'm asking them because I really don't
> understand your motivation for proposing this feature in the form that
> you proposed it.  It's your proposal, so only you can explain its
> details.

OK, glad to hear that.  Sometimes it's not clear.  Do you
understand now?  If not, do you think there is something
else I can add that would make things clearer?

The motivation is to be able to leverage face-occurrence
locations to manipulate (indirectly) text properties at
those locations.

We have functions - even user commands - that you can use
to change the attributes of a face, and doing that affects
all occurrences of the face (or all on a given frame,
optionally).

We can leverage these features to let users and code
(in effect) manipulate other text properties at whole
sets of locations at once.  Which locations?  Those of
a given face.

And we have umpteen ways to apply a face to different
locations - again, either by Lisp or user commands.

So users will be able to:

1. Put a face wherever they want (they can do that now).

2. Manipulate any text properties (that are supported)
   at those locations.

Please let me know if this is becoming any clearer
to you.  Neither of us wants to waste the time of the
other (and others), if there is no real communication
going on.