GNU bug report logs - #53294
29.0.50; Indirect font changes incorrectly affecting original buffer

Previous Next

Package: emacs;

Reported by: Andrew Hyatt <ahyatt <at> gmail.com>

Date: Sun, 16 Jan 2022 05:14:01 UTC

Severity: normal

Found in version 29.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Andrew Hyatt <ahyatt <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 53294 <at> debbugs.gnu.org
Subject: Re: bug#53294: 29.0.50; Indirect font changes incorrectly affecting
 original buffer
Date: Sun, 16 Jan 2022 16:41:44 -0500
On Sun, Jan 16, 2022 at 08:16 PM Eli Zaretskii <eliz <at> gnu.org> 
wrote: 

>> From: Stefan Monnier <monnier <at> iro.umontreal.ca> Cc: Andrew 
>> Hyatt <ahyatt <at> gmail.com>,  53294 <at> debbugs.gnu.org Date: Sun, 16 
>> Jan 2022 12:11:39 -0500  Some ways we can fix this:  - In 
>> `face-remap.el`, refrain from modifying the 
>> `face-remapping-alist` 
>>   by side-effects (i.e. avoid `delq`, `setcdr`, and friends). 
>>  - Add a `make-indirect-buffer-hook` and arrange for 
>> `face-remap.el` to 
>>   add a function there that does a deep enough copy of 
>>   `face-remapping-alist`. 
>>  - Remember that indirect buffers are an attractive nuisance 
>> and should 
>>   be deprecated (but note that I suspect the same bug affects 
>>   `clone-buffer` because it doesn't make a deep enough copy of 
>>   `face-remapping-alist` either). 
> 
> The last one tells me we are better with leaving this sleeping 
> dog lie. 

I agree the use of indirect buffers is problematic, but this 
problem actually results in user-visible bugs. Anyone who likes 
their org-mode buffer to be variable-pitch, and likes their 
capture buffer to be in a larger font (both pretty reasonable 
things), will run into this problem.

My patch fixes this in a way whose only downside is that it would 
be less efficient notably when you have a lot of face-remappings. 
But it's not clear to me that face-remapping-alist ever gets so 
big or is changed so often that this would be a problem.

The only other option is to fix this in org-mode, but they are 
cloning their indirect buffer presumably so that the capture 
buffer looks and behaves like the parent buffer, which is 
reasonable. I'd have to break that, or maybe just add a hack to 
deep copy face-remapping-alist.  Both options seem a bit wrong.




This bug report was last modified 3 years and 96 days ago.

Previous Next


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