From: Andrew Hyatt <ahyatt@gmail.com>
To: 53294@debbugs.gnu.org
Subject: bug#53294: 29.0.50; Indirect font changes incorrectly affecting original buffer
Date: Sun, 16 Jan 2022 00:13:26 -0500 [thread overview]
Message-ID: <m2y23gb6vd.fsf@andrews-mbp.lan> (raw)
[-- Attachment #1: text-scale-patch --]
[-- Type: application/octet-stream, Size: 590 bytes --]
diff --git a/lisp/face-remap.el b/lisp/face-remap.el
index 00560f9d2e..df35d88933 100644
--- a/lisp/face-remap.el
+++ b/lisp/face-remap.el
@@ -134,6 +134,11 @@ face-remap-add-relative
(let ((faces (cdr entry)))
(if (symbolp faces)
(setq faces (list faces)))
+ (setq face-remapping-alist
+ (mapcar (lambda (kv)
+ (if (eq (car kv) face)
+ (cons face (face-remap-order (cons specs faces)))
+ kv)) face-remapping-alist))
(setcdr entry (face-remap-order (cons specs faces)))
;; Force redisplay of this buffer.
(force-mode-line-update))
[-- Attachment #2: Type: text/plain, Size: 2185 bytes --]
Hi all,
I noticed a bug recently where if I scale up fonts in an org
capture buffer, it affects the original buffer, which keeps
getting bigger and bigger every time org-capture is run.
However, you don't need org to reproduce this. Here's a quick way
to reproduce, which works with emacs -Q:
(require 'face-remap) (defun ash/big-font ()
"Creates a font that is big enough for about 20 lines of text."
(interactive) (let ((text-scale-mode-amount (/ (frame-height)
20)))
(text-scale-mode 1)))
(defun ash/reproduce-with-indirect-buffer ()
(interactive) (let ((buf (get-buffer-create "*Orig buffer*")))
(set-buffer buf) (variable-pitch-mode 1) ;; same way org mode
creates indirect buffer (set-buffer (make-indirect-buffer buf
"*Indirect buffer*" 'clone)) (ash/big-font-new) (kill-buffer
(current-buffer))))
Running ash/reproduce-with-indirect-buffer will increase the
indirect buffer in size each time. If you look at
face-remapping-alist, it's clear that the original buffer's value
is being altered by the indirect buffer.
I traced this down to the setcdr in face-remove-add-relative,
which is incorrectly alterting a buffer local variable, by setting
parts of a variable in a way that will affect the original
variable. Evidently making something buffer local doesn't clone
it, it just copies the value, and so you can alter the original by
operations such as setcdr.
Assuming that the fixing how variables becomes buffer local is too
much, I've fixed this in face-remap.el. The patch is attached.
In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.2.0, NS
appkit-2113.20 Version 12.1 (Build 21C52))
of 2021-12-26 built on andrews-mbp.lan
Repository revision: 978987f7ad58cd66fe51cefde53ba4771b189aeb
Repository branch: master Windowing system distributor 'Apple',
version 10.3.2113 System Description: macOS 12.1
Configured using:
'configure --with-native-
Configured features:
ACL GLIB GNUTLS JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY
KQUEUE NS
PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS XIM ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
next reply other threads:[~2022-01-16 5:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-16 5:13 Andrew Hyatt [this message]
2022-01-16 9:22 ` bug#53294: 29.0.50; Indirect font changes incorrectly affecting original buffer Eli Zaretskii
2022-01-16 14:43 ` Andrew Hyatt
2022-01-16 15:00 ` Eli Zaretskii
2022-01-16 15:28 ` Andrew Hyatt
2022-01-16 15:41 ` Eli Zaretskii
2022-01-16 17:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-16 18:16 ` Eli Zaretskii
2022-01-16 21:41 ` Andrew Hyatt
2022-01-17 21:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-18 2:24 ` Andrew Hyatt
2022-01-18 2:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-19 2:37 ` Andrew Hyatt
2022-01-19 3:42 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 13:42 ` Lars Ingebrigtsen
2022-02-16 17:41 ` Anders Johansson
2022-02-17 11:41 ` Lars Ingebrigtsen
2022-02-17 13:38 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2y23gb6vd.fsf@andrews-mbp.lan \
--to=ahyatt@gmail.com \
--cc=53294@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).