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

[Drew Adams]

> > I have no idea where in the Emacs code particular text
> > properties are handled.  Some code, somewhere, takes care
> > of implementing their effects.
> 
> I tried to explain that with the example of the 'read-only' property.
> In a nutshell, every text property has special code somewhere in Emacs
> that examines that property to modify the behavior of the feature as
> the property instructs.  The only common infrastructure for that is
> the code which allows Lisp programs to add, remove, modify, and
> examine text properties at some position in a buffer or a string.  the
> effect of each property must be coded separately for every property.

You already made that clear.  And I already confirmed
that updates to the separate treatments for the different
properties would be needed.

Wherever the code is that handles a given text property,
if we decide that face specs should support that text
property then that code would need to be updated to
DTRT for it.

> > I don't know what triggers different kinds of such updates,
> > so I spoke in a general way about "redisplay".  Substitute
> > whatever wording you prefer, to indicate that there might
> > be (I don't know) some delay between (1) changing the face
> > property and (2) realizing the effect of doing so.
> 
> Not sure what you mean by "update" here.  The realization of the
> effect happens when the corresponding feature is used, so it isn't
> time-driven, it's event-driven.  For face attributes that affect
> display, that event is the next redisplay cycle, but for the
> non-visual attributes you propose the events will be entirely
> different, like buffer text modification for 'read-only'.

Right.  If it is an event such as buffer text modification
that checks text property `read-only' for the text where
the modification attempt is made, then the code that makes
that check during the modification attempt would need to
first check for a face property with a non-nil `read-only'
pseudo face attribute.  If present, it would do what it
normally does for a non-nil `read-only' text property (e.g.
raise an error).

For a property such as `keymap', the code that handles
a key sequence would need to check, first, for a face
property at point, to see if that property has a `keymap'
(pseudo) attribute, and if so, and if that key sequence
is bound in that map, do what it would do if the key
were bound in a `keymap' text property at that position.

The _code to check for the property_ would be the same,
for whatever property and wherever it might occur.  It
would be similar to what I showed before: check first
for property `face', `font-lock-face', or `mouse-face'
with a pseudo attribute that is the same as the text
property to check. If none, then go ahead and check
(as now), using code used now (presumably something
similar to or a C equivalent to `get-text-property').

The code to check for the property would be the same
for any property.  But the code that handles the
property, if found, would be different for each
property, of course.  That handling code would likely
be the same as today (no change or little change).

> Yes, I did grasp that.  But this single rationale is
> in effect a convenience feature, nothing more.

I don't mind if you put it that way.  All of Emacs is
convenience features...

This feature lets you do some things that you cannot
easily do now.  Call that convenience, if you like.

> It doesn't explain why this is
> more convenient than just putting the corresponding properties on
> those same stretches of text, nor why you'd like to avoid actually
> placing text properties to achieve the same goal.

Again, yes it does.  As I said, you need only change the
pseudo attribute value to nil in the face spec to undo the
change.  That undoes the change ONLY for the face occurrences.  
Likewise, for not undoing but changing to a different
property value (assuming several are possible).

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.

Probably the most commonly used text property is `face'
or `font-lock-face'.  Let users take advantage of those
zones that are already mapped out, applying and changing
other text properties there.

> Nor does it explain
> why the face property is being suggested as the vehicle
> for providing this feature.

> 'Face' is just one of the many text properties we
> support, and there's nothing in it that would make it a
> better means for implementing your convenience feature.

This convenience feature is all about using the face
occurrence locations.  We have them.  We could use them,
in this way (and possibly in other ways).

> At least I don't see why 'face' is better than any other
> property.

Well, it's the only property that makes sense for acting
on face locations (duh).  It lets you take advantage of
those locations, whether they are there from font-locking
or from ad hoc highlighting.  It lets you give such ways
of highlighting the ability to indirectly control other
text properties.

Whether you use font-lock highlighting or you highlight
by dragging the mouse over text (a "marking-pen"
highlighter) or you highlight in some other way, you
will be able to leverage the highlighting to act on
other text properties in highlighted zones.

> For example, would it work
> for you if we define a new text property, whose attributes will have
> the same effect as the corresponding text properties.  Would that be
> as good as your 'face'-based proposal?  If not, why not?

See above.  The point is to be able to take advantage of
existing highlighting (text properties, not overlays).

> > > And the same will have to happen with every feature
> > > which supports some text property.
> >
> > Correct.
> >
> > > This additional handling of face attributes will
> > > have to be replicated in every such feature;
> >
> > Correct - for every such feature we decide to support.
> >
> > > there are no single place
> > > to do that for all of them, AFAIU.  This is clearly additional
> > > non-trivial work, to be repeated in many Emacs features, which is a
> > > disadvantage.  Can you tell what would be the advantages justify
> > > that these additional costs?
> >
> > I can't speak to the cost.
> 
> I didn't ask you to.  What I did ask is what are the user-level
> advantages which would justify those costs, whatever they are.  I
> don't think you answered that question.

I've described the point of the feature - the advantages.
You've hinted at the cost.  Do the advantages outweigh
the cost?  I have no idea, because I don't know the costs.
And even if I did, my or your or John Doe's opinion of
whether the advantages outweigh the costs might well be
different.

And I won't be doing the C development work, so my
opinion about the worthiness relative to the cost is
not so useful.

I can't speak to the question of relative weight because
I don't appreciate the cost.  I can't speak to matters
that involve the cost - sorry.

> Such an answer is part of the
> rationale for the proposed changes; the absence of the answer is what
> makes it hard for me to understand the rationale, which is a
> prerequisite for reasoning about it.

You say that you have gotten the point, but I'm not
sure you have.  Asking "why faces?" really makes me
wonder, at this point.

If you have gotten the point then you see the utility
of the proposal.  Weigh that against the costs you
see in whatever way you see fit.

> > In an extreme example (but I'd hope it wouldn't be so limited,
> > even at the outset), support could be provided for only one
> > or two text properties (e.g. `invisible') to begin with.
> 
> Invisible is actually the odd one out, since it _is_ implemented by
> the display engine.  It's all the rest that puzzle me.

It's no different wrt other properties in regard to the
question raised: We could decide to support only `read-only'
or only `keymap' or only this and that, or whatever.

The point there was to make clear that your assumption
that I'm demanding that _all_ text properties be supported
(all or none) is off the mark.  Quite the contrary, as
I stated from the beginning.  It is important that any
text properties that are not supported be at least
tolerated (ignored) as face attributes, just as unknown
(e.g. user-defined) text properties are ignored by Emacs.

The point is to try to (1) make Emacs ignore unknown face
(pseudo) attributes, in general (put in place the necessary
infrastructure), and then possibly (2) begin to support
active handling of one or more of them.

> > I'm outlining a user-visible feature, not designing its
> > implementation.
> 
> I'm asking you to provide the rationale for the feature,
> and for attaching this feature to faces.

I believe I've done so, several times now: Be able to
leverage face locations (occurrences) and highlighting
commands/features and face-attribute commands, to (in
effect) control other text properties at those locations.

> So far you provided only a single
> rationale, for a single use case of the feature,

Dunno what you see as the single rationale, or the
single use case.

You can easily highlight zones of text in several ways.
Many zones are highlighted by font-locking, for instance.
A user or a program can want to do things to/with such
zones - things that involve text properties.

Is that one use case or a thousand use cases?  One
rationale or many?

> I'm asking to provide more use cases and at least
> some arguments for attaching this feature to faces.

I have nothing more to offer than what I've described.
Apparently that is both (a) too restrictive ("only one")
and too general - too complicated to implement.  Sorry,
but I can't add more to describe the feature as I see it.
Or if I can, please let me know what it is that would
help understanding.

> > Sounds like you're saying that it cannot be coded.
> 
> No, I didn't say that.  I'm saying that I still don't understand why
> it would make sense to provide such a feature, and why we should
> attach it to faces.  Please help me understand your reasons.

Does what I've said above, which repeats what I've said
in pretty much each mail so far, help?  If not, I'm
afraid I can't help you see better what is involved.

> > Anyway, you clearly are not interested in the idea,
> > if you are not outright hostile to it.
> 
> At this point, I'm interested in understanding the idea.  Only then I
> will be able to make up my mind about it.  I'm not there yet.

Clearly.

To be clear, in case it makes any difference: I have
no "ulterior" motive in suggesting this idea.  It just
happened to occur to me out of the blue, and the more
I thought about it the more I thought it was interesting
and could be useful.

Others can certainly think differently about it.  I lose
nothing particular if it is not implemented.  If it is
implemented I'm pretty sure that I would use it.  I don't
know just how/where I would use it.  It would be a new
feature that I would need to discover the practical use
of, just like anyone else.