bug#53636: 29.0.50; face-remapping broken on master

[Lars Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> When you remap a face, the faces that inherit from it are affected
> only on new frames, because when we create a frame, we recompute the
> set of the basic faces for it from scratch and thoroughly.  That's
> exactly the other side of the issue which started this discussion: the
> inheriting faces on the original frame aren't affected by the
> remapping of the parent face, but those same faces on new frames are.

Right.  There's two issues here, though, and I think both of them should
be fixed (but I don't know how difficult it would be).

1) `face-map-add-relative' is supposed to be buffer-local.  But the
example shows that faces that inherit from remapped faces are affected
in other (new) frames.  (The remapped faces themselves are not
affected.)

2) Remapping these base faces behave differently from other faces, and
it'd be nice to fix that.

>> Anyway, what I was thinking of is a really simple solution: Have
>> `face-remap-add-relative' loop over all children and remap them, too.
>> (I haven't actually attempted to write something like that, though.  😀)
>
> Why not leave this to the (small number of) applications that want to
> do this?

My feeling is that all users of face remapping would want this.

Eli Zaretskii <eliz@gnu.org> writes:

>> Anyway, what I was thinking of is a really simple solution: Have
>> `face-remap-add-relative' loop over all children and remap them, too.
>
> That'd mean looping over all the known faces for each change in
> face-remapping-alist, wouldn't it?  Because we don't track which faces
> inherit from a given face, we can only tell the reverse: from which
> faces a given face inherits.

Yes, but the number of faces is pretty small, so doing this looping in
`face-map-add-relative' would not impose a significant penalty overall.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no