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

Previous Next

Full log

Message #100 received at 53636 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#53636: 29.0.50; face-remapping broken on master
Date: Tue, 08 Feb 2022 20:57:28 +0200

> Date: Tue, 8 Feb 2022 19:24:19 +0100
> Cc: larsi <at> gnus.org, 53636 <at> debbugs.gnu.org, tsdh <at> gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  >> 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?
> 
> What makes you think that this is not part of my proposal?  What I mean
> is to have a clear rule how, for example, a buffer local setting of
> 'face-remapping-alist' may affect the creation of a new frame and the
> display of buffers in it.

OK, then we need first to agree on what is the reasonable expected
behavior in such cases.

Previous Next

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