Re: Local face remapping

[Eli Zaretskii]

> From: JD Smith <jdtsmith@gmail.com>
> Date: Thu, 5 Oct 2023 09:12:58 -0400
> Cc: emacs-devel@gnu.org
> 
> > In Emacs, faces are defined per-frame.  That is, each frame can have a
> > different definition of the same face symbol.
> > 
> > face-remapping-alist doesn't (and cannot) change that simple fact, so
> > it is a trick: it creates new faces based on default faces, in a way
> > that is buffer-local.  This works (btw, not in all places) because the
> > display engine consults the buffer-local value of face-remapping-alist
> > each time it needs to realize a face for display.  If that variable is
> > non-nil, and the face to be realized is mentioned in the alist, then
> > the display engine generates a new face on the fly and uses that new
> > face for display.
> 
> Interesting.  I presume with caching?

Yes, each frame has its own face cache (that is orthogonal to face
remapping).

> > So, if you want face-remapping that depends on buffer positions, you
> > will need to change the implementation of face-remapping: instead of a
> > simple alist, we will probably need to also allow a function returning
> > such an alist, and the C code will need to be taught to deal with
> > the situation where face-remapping-alist's value is a function.
> 
> That’s an interesting idea, more flexible than hard-coding a simple function 
> that considers START…END.  You wouldn’t want to call such a function for each 
> FACE character, and if the region divides a FACE interval, that adds 
> complexity. But maybe tractable.

Emacs only computes the faces when the face changes, so this is not a
significant complication, IMO.

> > My suggestion to use different faces just does explicitly what
> > face-remapping-alist does implicitly.
> 
> But much less efficiently, if the faces to be altered appear in many 
> non-contiguous intervals, and within ‘display strings in that (potentially 
> large) region.  The advantage of the “just in time” face substitution you 
> describe is it operates from the top down and is thus suitable for rapid 
> updates via, e.g., post-command-hooks. It also plays nicely with font-lock, 
> etc.

Maybe.  My idea was that the same code which decides that colors
should change can place the new faces on the text in the region, and
how heavy could that be?

> A perhaps related concept would be allowing code (including font-lock) to 
> apply secondary face(s) to text, via an alist, perhaps.  Secondary faces 
> would lie dormant, unless and until an overlay or text property explicitly 
> enables one of them (`use-secondary-face ‘foo', or similar).  In this way it 
> would be similar to mouse-face, but explicitly under programmatic control 
> instead of implicit mouse position control. An overlay or text property could 
> then be applied to an entire region enabling specific secondary faces within 
> it to “come alive”, quite similar to how mouse position causes mouse-face to 
> activate.

Actually, mouse-face is also under Lisp program control: see
mouse-highlight.