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

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

> > The idea is to allow the use of text properties as
> > attributes for the text (and overlay) properties `face',
> > `font-lock-face', and `mouse-face'.  This would apply to
> > faces used in strings (e.g., `propertize') as well as in
> > buffers.
> >
> > It would let you, for example, use a property such as
> > `invisible', `keymap', or `read-only' (even `display'?) as
> > part of a face definition.
> >
> > Any properties that either cannot be implemented or do not
> > make sense for faces would be excluded (i.e., ignored).  But
> > I'm guessing that most could be accommodated.
> >
> > Setting such a face attribute would have the effect that all
> > occurrences of text with that face, when redisplayed, would
> > appear as if the text property were applied directly to the
> > text that has that face.
> >
> > For example, this would make all doc strings invisible:
> >
> >   (set-face-attribute 'font-lock-doc-face nil 'invisible t)
> 
> Some comments/questions about this:
> 
> First, I don't understand why you want to "burden" faces and the
> display engine with this job.  It sounds like the job has nothing to
> do with faces per se, and that faces were chosen simply because
> font-lock is automatically applied by redisplay.  Is that right?

No.  It has nothing particular to do with font-lock.  As I said,
it is about (having the effect of) changing the text properties
at all occurrences of a given face, all at once (modulo redisplay
time)

> If so, I think we should consider alternative, more straightforward
> approaches.  For example, if what you are looking for is a way to put
> a specific text property on any text with a particular FACE,

The "if so" part is wrong - see above.

And this is not about actually putting a text property on the text.
This is about getting that effect without doing that.  The actual
text properties on the relevant text would be those that it had
before, with the exception that its `face' property would have
(pseudo face) attributes that correspond to non-face text properties.

The latter would be taken into account by the display engine, to
give the effect of their having been put on the text directly.

The indirection allows confining this behavior to the face
occurrences and removing it from only the face occurrences.

> I think
> you can write a function to do that by searching for face property
> changes and adding that property to each stretch of text with that
> FACE.

See above.

It is not about having a convenient way to directly alter the text
properties of the subject text.  It is about getting that effect
without altering them.  It is about associating that effect with
the particular face (only).

> Such a function can be written in Lisp, and doesn't require any
> infrastructure changes.  Would such a function do the job you had in
> mind?  We could make it part of Emacs, so people won't need to
> reinvent it each time.

No; please see above.  I'm not looking for a way to add text
properties wherever a given face property is present.  I'm
looking for a way to encapsulate a set of text properties
with a face, so they effect the display of text that has that
face, but they are not directly applied to the text.  They are
tied to presence of the face, and they can be changed or removed
by changing the face spec.

It's just about using the face as a "carrier" of text properties.

> Using the display engine for this job is also problematic in several
> other aspects:
> 
>  . It will slow down redisplay, because the display code will now have
>    to examine faces where it previously didn't.  For example, for
>    implementing invisible text: the current code looks just at the
>    invisible properties of text and overlays; under your suggestion it
>    will also have to look for faces.

Correct.

And more generally, it would affect tests for a text property.
As mentioned in my previous mail, I don't think that the current
functions (`get-text-property', `next-single-property-change, etc.)
that test for text properties should be changed.

Instead, we would add parallel functions that test for text
properties not just being directly present but also being
"present" by implication, i.e., indirectly, i.e., by way of
a face property.

I can't speak to the implementation (display engine etc.).
I'm glad that you are at least open to thinking about this,
since you are our expert on the display engine.  If the
idea is totally unfeasible or unrealistic, you would likely
be the one to speak to that.

If it affects performance significantly to also test for a
face property and check its attributes for a text property
then perhaps that extra check could be controlled by a global
variable.  IOW, if code needs this feature then it can "turn
it on", and otherwise the display engine would act as it has
in the past.

>  . Most text properties we support don't affect the display of text:
>    consider 'keymap' or 'read-only' or 'intangible' or
>    'modification-hooks', to name just a few.

Yes.  I addressed such properties specifically.  I don't know
where in the base code they are handled, so I spoke only of
"display engine".

But from a user point of view they would be handled the same
way in this suggestion.  The property would not be added to
the text, but rather it would stay as an attribute of the
`face' (or `font-lock-face' or `mouse-face') property.  It
would have the _effect_ of having been added to the text.
E.g., the text with the particular face would behave as if
it had the given `keymap' property value.

And yes, most Lisp code that tests text for such a property
would likely use a different function to test/obtain it.
For example, it would use `get-text-property-implied' (new),
which would check first for a face property that has the
given property as an attribute.  If present, that would be
returned; if absent then the `get-text-property' result
would be returned.

We could also, say, have `get-text-property-implied'
distinguish, in its result, whether the property was directly
present or was implied by virtue of being part of a face spec.

One way to do that might be to put the return value in parens
for one of the cases.  For example, if implied, the return
value could be a cons (FACE . VALUE), where FACE is the face
and VALUE is the value of the text property in its face spec.

(Maybe a slightly different convention should be used, as
that's not foolproof.  A text property that is directly
present could have a value of a cons whose car is a face.)

>    And of course,
>    applications can invent any properties they like.

I addressed that too.

>    How do you
>    expect the display engine to make your face attributes "appear as
>    if the corresponding text property was applied" to the text, if the
>    corresponding text properties don't affect the text appearance on
>    display?  The display engine doesn't apply any properties, it
>    produces glyphs for displaying text.

I said this:

  And let's not forget that anyone can create any text property
  (e.g. `jkjkljkl'), with any value, and apply it to some text.

  Some text properties that are not really related to faces
  are built-in (`emacs -Q').  Others are created by user code
  that alone determines how they behave - what their effect is.

A user-defined text property is unknown to `emacs -Q'.  It is
up to the code that defines it to do what it wants with it,
including (if it wants) any indirect use of it as a face attribute.

IOW, not Emac's problem.  User code will typically not expect
or need any such feature, and if it does then it will need to
take care of that itself.

> In addition, text property search will also become slower, for the
> same reason redisplay will become slower, as explained above.

Yes; see above, where I mention `next-single-property-change'
as one example.

> > Face merging is already well defined, in particular for
> > cases where there is a conflict between the values of the
> > same attribute, so I don't expect any problem there.
> 
> Not sure if this is relevant, but if it is, then the existing face
> merging won't help us, because it is only defined for visual
> attributes, not for the additional ones you want to define.

Either we could decide that that is acceptable, in which
case there would never be a conflict for such "attributes"
(e.g., the "latest" face spec applied would win, wrt their
effect - or only the first face spec would win), or we
could enhance the face-merging code to treat any unknown
face "attributes" similarly: have Emacs "apply" them as
if that were the only face.

> > One open question would be whether to allow the text
> > properties `face', `font-lock-face', and `mouse-face' as
> > properties for themselves and each other.  E.g., be able
> > to do this:
> >   (set-face-attribute 'face-1 nil 'face 'face-2)
> > or this:
> >   (set-face-attribute 'face-1 nil 'font-lock-face 'face-1)
> >
> > These properties could be excluded (ignored), but allowing
> > them might prove useful.  It would provide a simple way to
> > (e.g. temporarily) substitute one face for another
> 
> How is this different from overriding attributes of a face by those of
> another face, something I believe you can do today?

Not sure what you have in mind.  The above would have the
_effect_ of showing all occurrences of `face-1' as if they
were occurrences of `face-2', or (in the second example) of
handling them as if they were occurrences of `font-lock-face'.