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

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

> > IOW, I'm still struggling to understand why you attach this feature to
> > faces, and to faces only.
> 
> I may well be misunderstanding what Drew is asking for, because I didn't
> understand it the first four times he explained it, either.  But I think
> he's asking for something that works like a face, but includes all text
> properties.

Yes.  "Works like a face" is a good way to put it.

It is what I meant by leveraging existing, convenient ways
of applying (and unapplying), and specifying, faces.

Wrt "includes all text properties":

1. At least _tolerates_ all of them, ignoring any that w
decide not to teach Emacs to handle.

2. Includes _within a given face spec_.  The face definition
is used as an object that encapsulates a certain number of
non-face text properties.

Face A might use one value of text property `keymap', and
face B might use another.  In neither case would property
`keymap' be applied directly to the underlying text where
the face is applied.  Only the face property is applied
to the text (for this feature).

This lets you remove or change property `keymap' for all
occurrences of a given face.  And it lets Lisp code
distinguish properties that are attached directly to
the text and are thus not dependent on any face from
properties that are applied indirectly by way of the
face.

> That is:  He wants to say
> (defprop my-prop '(:read-only t :invisible nil :font "futura"))
> (set-text-prop (point-min) (+ (point-min) 4) my-prop)
> (set-text-prop (+ (point-min) 10) (+ (point-min) 20) my-prop)
> and then
> (set-prop my-prop :invisible t)

Nope.  That doesn't use faces at all.  It just attaches the
properties to the text directly.  It in no way lets you
leverage the features we have for applying faces, and it in
no way bundles the properties within a face spec, so that
changing the face changes (in effect) the properties of the
text where the face is applied.

> and then these two ranges would suddenly become invisible.
> So it's like...  a CSS selector...  kinda.
> 
> The thing is, I think you can just cheat and this thing is already
> available?  That is, just make my-prop a list, apply that list to the
> regions you are interested in, and then just mutate that list instead of
> using the property functions?  Or does set-text-properties copy
> PROPERTIES before putting them on the text?  I have neither tested nor
> read the source code.

See above.  Yes, you can already apply text properties
directly to text.  That's not what this feature is about.

And it's not only about being able to change a set of
props that is applied at various locations (though yes,
there is that effect from the proposal).  It's also
about taking advantage of face features, in particular,
convenient ways to apply them.

If you look at the fact that Emacs at one point added
to font-lock the ability to "manage" (to some extent)
other, non-face text properties, this feature is in
a similar vein.

Why did we add that extension to non-face props?
Because font-lock provides a _convenient way to
specify how and where to apply_ a property.

Imagine that!  Yep, font-lock applying a non-face
property is "just a convenience".  And a very
convenient one, too. ;-)  Do most users use it?
Probably not.  That doesn't mean we shouldn't
have added it.