GNU bug report logs - #53636
29.0.50; face-remapping broken on master

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, 53636 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: bug#53636: 29.0.50; face-remapping broken on master
Date: Tue, 08 Feb 2022 14:41:43 +0200

> Date: Tue, 8 Feb 2022 09:58:31 +0100
> Cc: 53636 <at> debbugs.gnu.org, tsdh <at> gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  >> And what happens when you call make-frame from another buffer is not a
>  >> bug?  Is face-remapping-alist supposed to affect the buffer in which
>  >> it is set on all frames or just on the single frame where
>  >> face-remap-add-relative was called?
>  >
>  > I'm not sure.  But the current behaviour (affecting all buffers on the
>  > new frame) has to be a bug.
> 
> Face remapping has never been properly synchronized with windows and
> frames.  What's needed is a simple hierarchy window > window's buffer >
> window's frame where the first should be implemented with the help of a
> 'face-remapping' window parameter and the last with the help of a
> 'face-remapping' frame parameter.  Just like we (should) do for things
> like the scroll bars or fringes.  But we need a consensus on this first.

I don't think I understand this remark.  While what you describe might
be a useful addition, I don't see why we must have it, or else.
Surely, Emacs has gobs of features that depend only on the buffer, but
not on the window nor the frame where that buffer is displayed?  Why
cannot we have a reasonable behavior with face-remapping-alist being
specific to a buffer, no matter in what window we display it?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.