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

[Eli Zaretskii]

> Date: Mon, 27 Mar 2017 09:22:23 -0700 (PDT)
> From: Drew Adams <address@hidden>
> Cc: address@hidden
> 
> > > Setting such a face attribute would have the effect that all
> > > occurrences of text with that face, when redisplayed, would
> > > appear as if the text property were applied directly to the
> > > text that has that face.
> > >
> > > For example, this would make all doc strings invisible:
> > >
> > >   (set-face-attribute 'font-lock-doc-face nil 'invisible t)
> > 
> > Some comments/questions about this:
> > 
> > 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.

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

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

And the same will have to happen with every feature which supports
some text property.  This additional handling of face attributes will
have to be replicated in every such feature; 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?

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

Do you see how any face attribute that has no effect on display will
not be "applied" as part of this processing?  The output of this
processing 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.