Re: region-based face-remapping

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 4 Jan 2024 02:07:36 +0200
> Cc: jdtsmith@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 03/01/2024 15:42, Eli Zaretskii wrote:
> >> Date: Wed, 3 Jan 2024 14:40:49 +0200
> >> Cc:emacs-devel@gnu.org
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> On 03/01/2024 14:31, Eli Zaretskii wrote:
> >>> The workhorse we use now for obtaining face information is the
> >>> function face_at_buffer_position, which calls the various face-merging
> >>> routines.  Those merging routines and their subroutines consider
> >>> face-remapping-alist as part of face merging process outlined above.
> >>> I don't see how we can avoid passing the buffer position to them if
> >>> face-remapping depends on buffer position.
> >> Perhaps face_at_buffer_position would first look up the overlay/text
> >> property 'face-remapping-alist, then merge its value with the variable
> >> face-remapping-alist (using plain 'append', for example), and pass on
> >> the resulting value to the face-merging routines?
> > Then any code running while face_at_buffer_position does its job will
> > see a tweaked value of face-remapping-alist, which is not necessarily
> > TRT, since it is not guaranteed that the buffer position being
> > examined by face_at_buffer_position is relevant to the rest of the
> > code.
> 
> I'm not sure I understand your response.
> 
> IIUC the request is that one would be able to change the faces' 
> appearances at any position in the buffer using a mechanism like 
> additional text properties or overlay properties.
> 
> It seems to reason that any code computing the 'face' for a buffer 
> position would need to account for the new property if it's set at that 
> position.

AFAIU, you suggested to temporarily tweak the value of
face-remapping-alist when face_at_buffer_position is called for a
position where the new proposed property defines a "local" remapping.
Is that right?  If so, imagine the following scenario:

  . face_at_buffer_position is called and tweaks face-remapping-alist
  . one of the subroutines of face_at_buffer_position calls some Lisp
    hook
  . that Lisp hook calls code that calls face-font (or some other
    primitive which takes face-remapping-alist into account)

In this scenario, primitives called in this way will see the tweaked
value of face-remapping-alist, which is specific to the buffer
position passed to face_at_buffer_position, whereas the code which
calls those primitives doesn't expect to be affected by such
position-local face remapping (for example, because it is interested
in some face in some other position).

Did I clarify my concern?