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

[Eli Zaretskii]

> Date: Mon, 27 Mar 2017 13:01:38 -0700 (PDT)
> From: Drew Adams <address@hidden>
> Cc: address@hidden
> 
> 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.

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

> > > And this is not about actually putting a text property on the text.
> > > This is about getting that effect without doing that.
> > 
> > What for?  You provided no rationale for having such "virtual"
> > properties.  The only rationale you provided is that of a convenience
> > feature which would allow to quickly and simply make specific portions
> > of text behave as if they have those properties.  I'm asking why not
> > actually give them those properties.  What does it gain us?
> 
> I did speak to that - several times now.  The point is to
> associate the effect with the face.  One feature of that
> is that you can change or remove the effect by changing
> or removing (setting to nil) the property in the face spec.
> Only text that has that face is to be affected.  Perhaps
> it is that part that you have not yet grasped.

Yes, I did grasp that.  But this single rationale is in effect a
convenience feature, nothing more.  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.  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.  At least I don't see why
'face' is better than any other property.  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?

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

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

If 'invisible' is the only one, i.e. you are asking for a feature that
would allow making text which has a certain face disappear from
display, that could perhaps be implemented without introducing any
face attributes.  IOW, it's a much narrower goal, and we don't
necessarily need to generalize it if no other use cases are apparent.

> 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.  So far you provided only a single
rationale, for a single use case of the feature, and that use case can
be catered to by different means which don't require any additional
infrastructure.  I'm asking to provide more use cases and at least
some arguments for attaching this feature to faces.

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

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