Re: region-based face-remapping

[Dmitry Gutov]

On 05/01/2024 10:19, Eli Zaretskii wrote:
> > I’m sure there could be lots of uses of this type of functionality, but 
> > “enhance the focus on one region
> > of importance” seems like a very common one.  For example, you might imagine 
> > dim/gray version of
> > all the font-lock faces outside the “treesitter region of interest” and bright 
> > ones inside.  Whenever that
> > TS-prescribed region changes, an overlay with a ‘face-remap property gets moved.
> 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; 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;

An overlay with face and higher priority would override most faces in 
the region, wouldn't it? Unless it just sets the background, in which 
case we already have this capability.

JD, have you considered it? E.g. set the default face's background to 
some darker color and use an overlay which sets background to a lighter one.

But if that's not sufficient, we could use a hook similar to what you 
(Eli) mentioned in the other subthread. Except instead of having a 
functions for face properties, it could be a global function that would 
be called on a "realized" plist of face attributes and return the 
adjusted one, for the point. The upside is that the display code won't 
have to look for another text property (and where its intervals start 
and end).

The downside, though, is that the realized plist might no be cache-able 
(the function can return a different value based on any number of 
conditions, right?). So either we document the requirement in text and 
simply expect the programmer to honor them (e.g. the returned face 
attributes must be stable WRT to buffer contents and not depend on time, 
for example), or simply avoid such a design. Same goes for callable face 
attributes.