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

[Drew Adams]

> > > 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?
> >
> > No.  It has nothing particular to do with font-lock.  As I said,
> > it is about (having the effect of) changing the text properties
> > at all occurrences of a given face, all at once (modulo redisplay
> > time)
> 
> But you explicitly mention "redisplay" above, and the display engine
> doesn't care about any properties unrelated to font-lock or faces.  So
> now I'm even more confused about the proposal.

Modulo "update" time, if you prefer.  (And this was
mentioned in paretheses, in hopes that it might help
understanding. You can ignore it if it does not help you.)

I have no idea where in the Emacs code particular text
properties are handled.  Some code, somewhere, takes care
of implementing their effects.

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.

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

> > >  . 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.
> >
> > Yes.  I addressed such properties specifically.  I don't know
> > where in the base code they are handled, so I spoke only of
> > "display engine".
> 
> Text properties that have no effect on display are not handled by the
> display engine.  They are handled by the features which implement the
> effects of those text properties.  For example, the read-only property
> is handled by code that modifies the buffer text: that code
> specifically examines the text to be modified, and if it has the
> read-only property, that code signals an error.  Under your proposal,
> the code which implements the read-only property will now have to
> examine face attributes of the text to be modified, in addition to the
> text property.

Correct.  I made that clear in my sketch of checking the
"effective" text-property value: any face property on
the text would need to be checked in priority, to handle
its text-property attributes, if there are any.

> 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.  You are doing so, which is good.
Yes, if we want to support a given text property then clearly
we will need to update the code that supports that text property

There is, however, no "requirement" that _all_ text properties
be supported.  I said clearly, in my first message:

  Any properties that either cannot be implemented or do not
  make sense for [associating with] faces would be excluded
  (i.e., ignored).  But I'm guessing that most could be
  accommodated.

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.
Support for more could be added if/when we (and users) see
that the support would be helpful.

> > > 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.
> >
> > Either we could decide that that is acceptable, in which
> > case there would never be a conflict for such "attributes"
> > (e.g., the "latest" face spec applied would win, wrt their
> > effect - or only the first face spec would win), or we
> > could enhance the face-merging code to treat any unknown
> > face "attributes" similarly: have Emacs "apply" them as
> > if that were the only face.
> 
> The display engine doesn't apply face attributes in the sense that you
> seem to use this terminology.  It examines face attributes and
> determines what typeface, colors, fonts, etc. to use to display the
> characters which have those face attributes.  IOW, the only output of
> face attribute examination is the description of what should be on the
> screen, and that description is then used by the terminal-specific
> interface to actually display that on the glass.

I didn't say anything about the display engine there.

What would needs to be done in terms of the implementation I
leave to those knowledgable in that.  Whether existing code
that "examines face attributes" should be extended to DTRT
for this feature or some other code should be brought in to
do that is not my concern.

I'm outlining a user-visible feature, not designing its
implementation.  There may be no interest in the feature.
Or there may be interest in it but it might be deemed
unfeasible or too costly in terms of implementation.

> Do you see how any face attribute that has no effect on display
> will not be "applied" as part of this processing?

I don't even know how to parst that question.  Maybe try
to rephrase it?

> The output of this processing

What processing are you talking about?

> is not buffer text modified in some way, it's an entirely
> different set of data structures which are not even visible from Lisp.
> There simply isn't any place there to record the face attributes you
> propose to add.

Sounds like you're saying that it cannot be coded.  Too bad,
in that case.  Anyway, you clearly are not interested in the
idea, if you are not outright hostile to it.  Since it would
no doubt need your participation to be implemented I guess
it's dead in the water.