Re: region-based face-remapping

[Eli Zaretskii <eliz@gnu.org>]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Sat, 6 Jan 2024 08:53:22 -0500
> Cc: emacs-devel@gnu.org
> 
>  This makes sense, thanks.  In the ‘face-remap property scenario, the number of such ‘face
>  property-change positions doesn’t actually change.
> 
>  I don't think this is true. If the 'face-remap' property changes at
>  some buffer position, the realized faces need to change there,
>  although the 'face' property didn't change. So with the 'face-remap'
>  property, we'd need to arrange for face-merging also where the
>  'face-remap' property changes, not only where the 'face' property
>  changes.
> 
> I wondered about that.  Since I don’t know emacs internals, I am (blissfully?) unaware of how close at
> hand the information of (get-text-property (point) 'face-remap) is.  Since a typical buffer has maybe
> N=hundreds of ‘face changes, this puts an approximate upper limit on the number of sensible ‘face +
> ‘face-remap changes: 2N.  Much more likely would be just a handful of ‘face-remap changes.  So I
> doubt the overhead of “additional merging” would be significant.  Of course you have to find these
> special points, but already you must find ‘face and ‘font-lock-face (and others?).

I only wrote the above because you said that "the number of such
'face' property changes will not change".  I'm saying that it _will_
change, and moreover, that the display engine will need to search for
this new property, in addition to the properties it searches for
already.  Whether this will add significantly to the processing
requirements, I don't know, because I don't have a clear idea what
application-level features you have in mind.  I do know that, like the
proverbial wisdom of "640KB should be enough for everyone", any
assumptions in Emacs that some feature will be used only "a little"
eventually becomes false.  We have ample examples of that:

  . the number of overlays in a buffer, which recently caused us to
    radically change how overlays are stored
  . the number of faces on a frame, which recently caused us to
    radically change how a frame's faces are stored

and there are other examples.

>  How many faces do you have defined on that frame?  I'm guessing not
>  many, or maybe they are all almost identical (differ in only one or
>  two simple attributes).
> 
>  Right now it’s just a couple of faces (remove one face-remap, add another).  If I had
>  access to a
>  ‘face-remap property, I could imagine maybe 10 faces at most being affected as point
>  changes. 
>  Each face would change by one or two attributes like foreground, stipple, etc.  
> 
>  What matters is the total number of named faces defined for the frame,
>  not the number of faces affected by face-remap.
> 
> I define the faces on the fly based on max indentation depth, but in practice it’s of order 5 more than
> the normal contingent of a dozen or so font-lock-faces.  So not a huge number.

Maybe not in your use patterns, but some users here reported many
hundreds of faces on each frame.  It is the reason why we changed
frame-face-alist to use a hash table instead.

With many faces defined for a frame, recomputing all of them is a
process that visibly slows down certain operations in Emacs.

>  The question I suggest to ponder is whether simpler, less general ways
>  to implement these features are "good enough".  For example, changing
>  the appearance of a region of text can be handled by moving an overlay
>  there with a suitable face definition and high priority; 
> 
> Indeed I have pondered this for several months and found nothing suitable.  Do you have any specific
> approaches to consider, which would allow you to selectively affect the appearance of certain small
> ranges of text within a (much) larger region of text?  The problem is, the region is well known, but
> changing the appearance everywhere within it is not suitable to the problem at hand.  I could
> obviously scrub through the entire region on the fly replacing face properties as I go (including inside
> ‘display properties), but that’s painful and probably too slow for interactive use.

I cannot be of more help here without understanding better what kinds
of application-level features you want to support.  Until now, you
only described that in very general terms.

>  changing the appearance of text around point can be handled by a special variable
>  which the display engine will consider when working on text around
>  point; etc.  
> 
> I’m afraid I don’t understand your “special variable to consider for text around point” idea.  Can you
> give an example of how this could work in practice?  How would such a variable be updated and
> associated with text, if not via text properties?

It could be a buffer-local variable, which defines the size of the
region around point where the faces should change their appearance,
and how to change the appearance.  The display engine then could take
that into consideration when processing buffer positions around point.

Whether this makes sense depends on the applications you have in mind.

> If you have other simpler ideas in mind that would allow turning on and off a latent “plane” of varying
> face information within a region of text (information which, I should have mentioned, could easily be
> computed and pre-applied by font-lock), I’d be very glad to hear them.
> 
> In the world of CSS, you’d do this quite simply by (say) updating the class of the div which wraps your
> text of interest, and having special styling for, e.g., "alternate bold" and "alternate italic”, which is only
> activated when the “alternate” class is applied:
> 
>  <div class=“normal”>
> 
>  This is <i>some italic text</i> and <b>some bold</b> text.  This is unrelated text.
> 
>  </div>
> 
>  In CSS
> 
>  .alternate b {...}
>  .alternate i {…}
> 
>  (In JS later:)
> 
>   myDiv.classList.add('alternate');

You are describing how to specify the effect, whereas I'm bothered by
the implementation which could support that.  Faces in Emacs are
specific to the entire frame, and we have face-remapping to change
that within limits buffer-locally.  We don't currently have any
infrastructure that allows the faces to change on a finer resolution,
except if the Lisp program modifies the 'face' text properties or
defines overlays with 'face' properties.