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

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

> > That's the point.  The text-property fiddling is confined
> > to a particular face.  It affects all occurrences of the
> > face (or all on a given frame, optionally).
> >
> > That's one advantage.  Another is that we have commands
> > that let users easily apply faces to text in various ways
> > (match regexps,... whatever).  Another is that users
> > already have lots of locations where faces are applied -
> > common and significant locations, for users.  So this
> > feature has plenty of terrain of immediate application.
> 
> Why would I want to make all stretches of text that have, say,
> font-lock-constant-face have a particular 'keymap' attribute?

Dunno why you would, Eli.  Maybe you wouldn't.
I probably wouldn't (why would I?).

But you might want to use font-lock to place a
`keymap' property on particular zones of text,
defined syntactically. IOW, you might want to
take advantage of font-lock's elaborate
specification possibilities to locate places to
put a given `keymap' property.

Yes, you can also do that now, by giving a spec
to font-lock  that contains the text properties,
and adding those properties to
`font-lock-extra-managed-props'.

The proposed feature provides more flexibility
for that kind of thing.  You can change a face's
spec anytime, to change the effects for only
_that face's_ occurrences.

A face need not show any highlighting, even now
(its attributes could just reflect the default
face).  With the proposed feature a face could
certainly provide _only_ non-face text properties,
if that makes sense in a given context.

E.g., a given font-lock spec could have as its
purpose to _only_ place a given `keymap' (or
`syntax-table' or whatever) property at particular
locations, defined syntactically.

(Again, you could get that effect now, using
`font-lock-extra-managed-props', but without the
flexibility just mentioned.)

And beyond font-locking, there are lots of other
ways to "highlight" text with a given face.

And for such ad hoc highlighting you do not
necessarily want the highlighting (including
application of other text props) to go away just
because you turn off font-lock mode.

Highlighting is more general than just font-locking.

Since with the proposed feature a face can be a
carrier of text properties, the notion of
"highlighting" using a face takes on more meaning.

Highlighting in the usual sense might be one of the
effects - or not.  Text properties, besides just
those affecting appearance, can now be part of any
"highlighting".

When I said "users already have lots of locations
where faces are applied - common and significant
locations" I wasn't referring only to using
locations that were chosen for text highlighting
in the ordinary sense.

I mean both that those face occurrences _can_ be
taken advantage of and that _non-highlighting
occurrences_ of a face can also exist.  The meaning
of "places where faces are applied" is expanded.

> And how is that more convenient than simply scanning the text
> for the same regexp/syntax as the one which used to place the
> face and actually putting a 'keymap' property there?

Do you ever use font-lock?  How is it more
convenient for you that explicit code that
searches for each regexp/syntax construct and
puts the relevant face on it?  Clearly it is, no?

Likewise, for the many other ways of highlighting
text.  There are convenient ways to highlight
text, but you aren't forced to use them.  If you
prefer to always "simply" scan the text and apply
a face, you are free to do that instead. 

> And why do you only ask this for the 'face'
> properties, but not for others?

I've answered that several times now.  It's hard
to believe that you are really trying to get the
message.

If you cannot see the convenience of being able
to apply text properties just by using existing
means of highlighting (and not just font-locking)
then I don't think there's a lot more I can do
to convince you. 

> IOW, I'm still struggling to understand why you
> attach this feature to faces, and to faces only.

Yeah, you keep asking me that.  And I keep telling
you my reasons, in different ways - but the reasons
remain the same.

Do you see something besides faces that offers the
same convenience for applying properties to text?
I proposed leveraging faces, but if you see another
potential affordance for doing that, maybe we can
consider that one too.

> Please also note that at least font-lock faces are by
> default placed lazily, on and around the portions of
> the buffer that are going to be displayed.  So Lisp
> programs looking for your special attributes might not
> find them if JIT font-lock didn't yet fontify them.

Yes, by default font-locking is lazy.  That would of
course apply also to the use of a face whose spec
contains text-property (pseudo) face attributes, as
well as to any other face.

And just as you see text fontified when it becomes
exposed in the window, so would the text props in
its face be realized as the text becomes exposed
in the window.  You cannot use a property such as
`keymap' without moving point to the text that has
that property, in which case the text is also shown
in the window.

If there are any text props (that we decide to support
for this feature) for which lazy realization is not
good enough then they wouldn't be good candidates for
use by font-lock (unless font-lock is used by the user
eagerly instead of lazily).

> Am I correct concluding that the advantages, from your POV,
> are that users of this feature will be able to avoid the
> need of specifying the text to receive this special
> treatment with regexps, syntax classes, and other similar
> means, and instead will be able to use the definitions
> already provided for faces?

By "this special treatment" are you referring to
(effectively) applying non-face text props?  And is
"the text to receive" that treatment the text where
faces are applied (in my proposal)?

If so, then yes: Leverage the many convenient ways
we already have to apply a face to zones of text.

(Not sure what you mean there by "the definitions
already provided for faces."  Face definitions don't
specify where the faces get applied.)

> Is this the only advantage, or are there others?

Is it one advantage or two (or several)?  I said:

  I chose face properties not by accident, but because the
  feature would let you leverage both (1) existing face
  locations (occurrences), and (2) existing commands and
  other functions that let users and Lisp easily put a face
  property on text in various ways, or change it.

  Faces are special in those senses - they constitute
  especially handy affordances for manipulating text at
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  locations that are common or significant for users.

It's about (indirectly) applying text props and
manipulating applied text props, in convenient ways.

Those are the advantages I see, for why we would turn
faces into carriers of arbitrary text properties (at
least those we decide to support).

> > 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.
> 
> Why is it better than just put any property you need,
> such as 'read-only', directly on that same text?  What 
>non-trivial parts of the job would be saved by using
> face attributes instead?

See above and my other replies.  Faces are convenient.
There is a lot more provided to users for highlighting
(i.e., using faces) than there is for placing arbitrary
text properties.

And by encapsulating text props within a face we can
easily manipulate different bunches of them individually.

They are not just all `font-lock-extra-managed-props',
i.e., handled all the same, together, wherever they are
used.

> > Faces are special in those senses - they constitute
> > especially handy affordances for manipulating text at
> > locations that are common or significant for users.
> 
> If this is the answer to my question above,

It's part of the answer.  Look above, and in previous
replies, for more.

> then I'm not sure I agree
> with you.  E.g., Text mode has no faces by default, but
> that doesn't mean Lisp programs working in Text mode
> won't want to manipulate text at significant locations.

1. I didn't say that this feature would or should be
the only way for Lisp programs to manipulate text.

2. Wrt both Lisp and interactive use: Who cares what
Text mode has by default?  Please try to get beyond
font-lock and especially beyond default font-locking.

I can highlight text in Text mode in many ways helpful
and meaningful to whatever current use I'm making of
Text mode.  That includes but is not limited to
non-default font-locking.  I use ad hoc highlighting
all the time (with text props and with overlays).

Sure, maybe some users don't, and maybe some users
never fiddle with `font-lock-keywords'.  No one would
be forced to use this feature either.