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

[Eli Zaretskii]

> Date: Sun, 26 Mar 2017 12:14:38 -0700 (PDT)
> From: Drew Adams <address@hidden>
> 
> 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?  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, 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.  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.

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.

 . 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.  And of course,
   applications can invent any properties they like.  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.

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

> 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.

> 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?