bug#53294: 29.0.50; Indirect font changes incorrectly affecting original buffer

[Andrew Hyatt <ahyatt@gmail.com>]

On Sun, Jan 16, 2022 at 08:16 PM Eli Zaretskii <eliz@gnu.org> 
wrote: 

>> From: Stefan Monnier <monnier@iro.umontreal.ca> Cc: Andrew 
>> Hyatt <ahyatt@gmail.com>,  53294@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.