From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Matthew Malcomson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Mar 2023 13:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 62419@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16796652936830 (code B ref -1); Fri, 24 Mar 2023 13:42:02 +0000 Received: (at submit) by debbugs.gnu.org; 24 Mar 2023 13:41:33 +0000 Received: from localhost ([127.0.0.1]:40031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfhfg-0001m6-I2 for submit@debbugs.gnu.org; Fri, 24 Mar 2023 09:41:32 -0400 Received: from [209.51.188.17] (port=56186 helo=lists.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfhfc-0001lm-5a for submit@debbugs.gnu.org; Fri, 24 Mar 2023 09:41:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pfhfV-0001wD-UA for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 09:41:21 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pfhdG-000342-NJ for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 09:41:21 -0400 Received: by mail-wr1-f41.google.com with SMTP id h17so1822234wrt.8 for ; Fri, 24 Mar 2023 06:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679665078; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=R0pgfQltGADi4VTZQwQMiledUMehW6Bz3jyY7RfNqYU=; b=btsewsi73MraonH4bJDkTR5DKwGDKKLuWECwkiD72RWpNuzxoC+j5zbIpQhqcqhMXa SAW0APbVrZCK6jet81qq4Qn7roDwSlgtDY4pKrm47jIGn/XhDJUhIXF7R3n95CpuYE+p e3RlujuJRJUZz6yYngFEfhVaUNRfkVRys1tOBebrqnWGUgtBQd+s0Zi6Y7rT+0R+vhy/ s3pDpx+T3F/q+xEUEC9fHR3KCQhrCn2mUT31qRrCbH5HvSNSAW/Df5iYGJIIM7kPKXT2 GxZ7Amv+B8xx32T+h88zH3Az+0oYQQLS1TQ3ge/bgSlmkcIUZOfDP8unij5XS+THrh0h fjqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679665078; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=R0pgfQltGADi4VTZQwQMiledUMehW6Bz3jyY7RfNqYU=; b=YIZ+T2nubY8WIqaSEQRu9Lfi7GjgroPVrP+vw5duNuQ6tFtGDRG8mEa7WMLoUopVJx ndxQueIdelxBsE0LM2zALSXcbt7U+HTgfZOZkbRFRD4y0py7jhjG9ZxA83n+sRM4z0yF yD5HiC++QE6yFPg52BfeC0QyThT3x4QAR+e2o+sBJj+eQDdgDbKr4T2w3rChuO+bFsz0 U2AM/sCAxYXRhQbitEuLqnWYh797GmecrQJYXcJyMWfBcAUywnorDOgNNF7piZvRZ4tI FHBdH7Amk9v/KIXzFq3+/Lf8u7agPmPxDkBVC2eigrkATgF+soL30sOqxpiVRv7H77Ie OmDQ== X-Gm-Message-State: AAQBX9eqLcfU0YByzPZ1johxEr7Th2baFSLIqGtN4NXp2Bu/s5o5HaZ8 e3v40Usy1IA7EQhnkyvv6ICc2uHjnAM= X-Google-Smtp-Source: AKy350ZkFi1qtzKFks6NMK0DxYAZLNX7q2rZRjWdn/NHqskHVg7UOQV+EMQ4yXUNI1EsJoxUlNvugg== X-Received: by 2002:adf:e6ca:0:b0:2ce:adff:61fc with SMTP id y10-20020adfe6ca000000b002ceadff61fcmr2192722wrm.37.1679665078511; Fri, 24 Mar 2023 06:37:58 -0700 (PDT) Received: from smtpclient.apple ([2a00:23c6:5484:ac01:e12d:76f0:ef75:d129]) by smtp.gmail.com with ESMTPSA id p14-20020a5d48ce000000b002d45575643esm16390512wrs.43.2023.03.24.06.37.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2023 06:37:57 -0700 (PDT) From: Matthew Malcomson Content-Type: multipart/mixed; boundary="Apple-Mail=_0BB9BE86-326B-47CF-A415-8D41F45FD27A" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Message-Id: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> Date: Fri, 24 Mar 2023 13:37:57 +0000 X-Mailer: Apple Mail (2.3693.60.0.1.1) Received-SPF: pass client-ip=209.85.221.41; envelope-from=hardenedapple@gmail.com; helo=mail-wr1-f41.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) --Apple-Mail=_0BB9BE86-326B-47CF-A415-8D41F45FD27A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I=E2=80=99m inlining some elisp which has behaviour I find unintuitive. To view the bug I would run each top-level form with C-x C-e in turn in = an elisp buffer. This behaviour may be expected =E2=80=94 the manual mentions something = related =E2=80=94 but I believe this is an unintended edge-case. N.b. the use of `auto-fill-function=E2=80=99 is just for a variable = which turns buffer-local when set, not as anything related to this = particular symbol. FWIW I believe this behaviour to be the root cause of = https://github.com/joaotavora/yasnippet/issues/919 (which was closed due = to not being able to reproduce it). =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 ;; Ensure that `auto-fill-function' has a buffer-local version and a = global ;; version. (setq auto-fill-function 'local-symbol) (describe-variable 'auto-fill-function) ;; `auto-fill-function' is let-bound in the buffer scope (let ((auto-fill-function 'temp-symbol)) ;; Now there is no buffer-local variable for `auto-fill-function', but = the ;; `let' unwrapping info is still there. (kill-local-variable 'auto-fill-function) ;; Since the check in the emacs source is ;; a) Is there a buffer-local variable. ;; b) Is there a let-binding shadowing the current variable. ;; Then this `setq' sets the *global* variable. (setq auto-fill-function 'other-symbol)) ;; Exiting the `let' has special handling to avoid resetting a local = variable ;; when the local variable was `let' bound, which means that overall the = `setq' ;; set the global variable and the `let' has been lost. (describe-variable 'auto-fill-function) =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 I think the final state after having done the above should be: 1) Global value has not changed. 2) Local value has not changed. While the observed state after the above is: 1) Global value has been set to `other-symbol'. 2) Local value has been removed. - The `setq` inside the `let` sets the *global* value rather than = creating a buffer-local variable. - The `let` on the buffer-local version of the variable is lost. The manual for `make-variable-buffer-local` =E2=80=94 in `(elisp) = Creating Buffer-Local` =E2=80=94 does mention that if a variable is in a = `let` binding then a `setq` does not create a buffer-local version. That said, I=E2=80=99m guessing the intention of this behaviour is so a = `let` binding on a global variable is modified rather than bypassed by a = `setq`. I=E2=80=99d suggest that is not relevant to the above code since the use = of `kill-local-variable` means the `let` is effectively lost already = (e.g. it does not get =E2=80=9Creset=E2=80=9D on an unwind). I=E2=80=99m attaching the source code hack that I=E2=80=99ve started = using to work around this. I=E2=80=99m not proposing this as a change, just including it for extra = context about the cause. I *believe* that the form of the C code around here looks like the = special case of a forwarded variable not having a buffer-local value but = having a buffer-local `let` binding could easily have been an oversight = rather than intention. (N.b. for this hack I guessed the meanings of the `let` enum values). --Apple-Mail=_0BB9BE86-326B-47CF-A415-8D41F45FD27A Content-Disposition: attachment; filename=emacs-patch.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="emacs-patch.diff" Content-Transfer-Encoding: 7bit diff --git a/src/data.c b/src/data.c index 57205d8..af427ea 100644 --- a/src/data.c +++ b/src/data.c @@ -1607,7 +1607,7 @@ set_internal (Lisp_Object symbol, Lisp_Object newval, Lisp_Object where, if (idx > 0 && bindflag == SET_INTERNAL_SET && !PER_BUFFER_VALUE_P (buf, idx)) { - if (let_shadows_buffer_binding_p (sym)) + if (let_shadows_buffer_binding_p_and_is_global (sym)) set_default_internal (symbol, newval, bindflag); else SET_PER_BUFFER_VALUE_P (buf, idx, 1); diff --git a/src/eval.c b/src/eval.c index d002e81..9200d71 100644 --- a/src/eval.c +++ b/src/eval.c @@ -3491,6 +3491,25 @@ let_shadows_buffer_binding_p (struct Lisp_Symbol *symbol) return 0; } +bool +let_shadows_buffer_binding_p_and_is_global (struct Lisp_Symbol *symbol) +{ + union specbinding *p; + Lisp_Object buf = Fcurrent_buffer (); + + for (p = specpdl_ptr; p > specpdl; ) + if ((--p)->kind == SPECPDL_LET_DEFAULT) + { + struct Lisp_Symbol *let_bound_symbol = XSYMBOL (specpdl_symbol (p)); + eassert (let_bound_symbol->u.s.redirect != SYMBOL_VARALIAS); + if (symbol == let_bound_symbol + && EQ (specpdl_where (p), buf)) + return 1; + } + + return 0; +} + static void do_specbind (struct Lisp_Symbol *sym, union specbinding *bind, Lisp_Object value, enum Set_Internal_Bind bindflag) diff --git a/src/lisp.h b/src/lisp.h index 0cad97c..0a296cd 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -4221,6 +4221,7 @@ extern void mark_specpdl (union specbinding *first, union specbinding *ptr); extern void get_backtrace (Lisp_Object array); Lisp_Object backtrace_top_function (void); extern bool let_shadows_buffer_binding_p (struct Lisp_Symbol *symbol); +extern bool let_shadows_buffer_binding_p_and_is_global (struct Lisp_Symbol *symbol); /* Defined in unexmacosx.c. */ #if defined DARWIN_OS && defined HAVE_UNEXEC --Apple-Mail=_0BB9BE86-326B-47CF-A415-8D41F45FD27A-- From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Mar 2023 11:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Matthew Malcomson , Stefan Monnier Cc: 62419@debbugs.gnu.org Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.167974527615242 (code B ref 62419); Sat, 25 Mar 2023 11:55:02 +0000 Received: (at 62419) by debbugs.gnu.org; 25 Mar 2023 11:54:36 +0000 Received: from localhost ([127.0.0.1]:41905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pg2Tj-0003xm-Hk for submit@debbugs.gnu.org; Sat, 25 Mar 2023 07:54:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pg2Th-0003xV-Ae for 62419@debbugs.gnu.org; Sat, 25 Mar 2023 07:54:33 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pg2PH-00079L-5f; Sat, 25 Mar 2023 07:49:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=xwECM2Do3qNFNOx9BhQzVqfohdy4ldtn8/bn4M/iREA=; b=BDMe7p8MljkPlUB48kkz KTT8lfEf6vs6oqMPPtrx79dXHuVApgHhbO3b4N/NXaOaZtfiv6OYvzwmbC6amd1QXCnS5RyOK0Ews SLEIAYQ4kPkd87/ihoATCjszcIOkZmt2H4yepHxej5DpckJ/kCQt/hgHwTTy2hCGQ9Gr4Chgqzc8/ pXc+u5zckfZRQrMAyPKx0AXeEbjiWwR2hbRikDjjOJXjH1siefclhZYF+DUqWmqW8fiKkuOAaBzw3 1o4lzMvSn5IkJYSHD29rIUrPGSn2tkVAoeUI8Q35Jrfc8VahoYzMpE0Lp0RRBgq1oqvtZp/4Bf5+A wr6YRtJSzyuPZw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pg2PG-0000iw-JO; Sat, 25 Mar 2023 07:49:58 -0400 Date: Sat, 25 Mar 2023 14:49:54 +0300 Message-Id: <83v8ipcaot.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> (message from Matthew Malcomson on Fri, 24 Mar 2023 13:37:57 +0000) References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) > From: Matthew Malcomson > Date: Fri, 24 Mar 2023 13:37:57 +0000 > > I’m inlining some elisp which has behaviour I find unintuitive. > To view the bug I would run each top-level form with C-x C-e in turn in an elisp buffer. > This behaviour may be expected — the manual mentions something related — but I believe this is an unintended edge-case. > N.b. the use of `auto-fill-function’ is just for a variable which turns buffer-local when set, not as anything related to this particular symbol. > FWIW I believe this behaviour to be the root cause of https://github.com/joaotavora/yasnippet/issues/919 (which was closed due to not being able to reproduce it). > > ————— > ;; Ensure that `auto-fill-function' has a buffer-local version and a global > ;; version. > (setq auto-fill-function 'local-symbol) > (describe-variable 'auto-fill-function) > ;; `auto-fill-function' is let-bound in the buffer scope > (let ((auto-fill-function 'temp-symbol)) > ;; Now there is no buffer-local variable for `auto-fill-function', but the > ;; `let' unwrapping info is still there. > (kill-local-variable 'auto-fill-function) > ;; Since the check in the emacs source is > ;; a) Is there a buffer-local variable. > ;; b) Is there a let-binding shadowing the current variable. > ;; Then this `setq' sets the *global* variable. > (setq auto-fill-function 'other-symbol)) > ;; Exiting the `let' has special handling to avoid resetting a local variable > ;; when the local variable was `let' bound, which means that overall the `setq' > ;; set the global variable and the `let' has been lost. > (describe-variable 'auto-fill-function) > ————— > > > I think the final state after having done the above should be: > 1) Global value has not changed. > 2) Local value has not changed. > > While the observed state after the above is: > 1) Global value has been set to `other-symbol'. > 2) Local value has been removed. > > - The `setq` inside the `let` sets the *global* value rather than creating a buffer-local variable. > - The `let` on the buffer-local version of the variable is lost. What is the purpose of doing this? what are you trying to accomplish, and why? > The manual for `make-variable-buffer-local` — in `(elisp) Creating Buffer-Local` — does mention that if a variable is in a `let` binding then a `setq` does not create a buffer-local version. > That said, I’m guessing the intention of this behaviour is so a `let` binding on a global variable is modified rather than bypassed by a `setq`. > I’d suggest that is not relevant to the above code since the use of `kill-local-variable` means the `let` is effectively lost already (e.g. it does not get “reset” on an unwind). Did you also read about default-toplevel-value and set-default-toplevel-value (in the "Default Value" node of the ELisp manual)? > I’m not proposing this as a change, just including it for extra context about the cause. > I *believe* that the form of the C code around here looks like the special case of a forwarded variable not having a buffer-local value but having a buffer-local `let` binding could easily have been an oversight rather than intention. Stefan, any comments? From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Matthew Malcomson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Mar 2023 16:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62419@debbugs.gnu.org, Stefan Monnier Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.167976120712454 (code B ref 62419); Sat, 25 Mar 2023 16:21:02 +0000 Received: (at 62419) by debbugs.gnu.org; 25 Mar 2023 16:20:07 +0000 Received: from localhost ([127.0.0.1]:43310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pg6cg-0003Ek-IL for submit@debbugs.gnu.org; Sat, 25 Mar 2023 12:20:06 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:45781) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pg6ce-0003E7-JF for 62419@debbugs.gnu.org; Sat, 25 Mar 2023 12:20:06 -0400 Received: by mail-wr1-f44.google.com with SMTP id r11so4589689wrr.12 for <62419@debbugs.gnu.org>; Sat, 25 Mar 2023 09:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679761198; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qLtdzZNUNvDWRCRQ9e+GAD8sIBUs/8gQPsfCU/fHYAA=; b=RgsNbIh5jnXRG0XrTloXcSjOuDhHnElSMSJYAWqAMHG5Vn8AGn+5qXdQTw+Bfj348+ fq+BTeNOv7KS2WiKdslg+y0k5bj/+oywHDap/5lzT/oUVTzVqRxx1vRi91NzL1QInm0p 9A3N+KBk0myaUwUHYFHYA7oJkJpdjcfgatKQV37yyYIXW+BWp3G5pA1obaYDkLjm8fol NEqpVtfiN78iaNspJDgOy6cLem/TeM+Al7UH0Qcd3QG3v6CLHZMQb1cZw31Xkzf2pnwP kAJTvg5gFD0pcA3PTS7Q9L8vDAJ8GbEy25RmLZzgX2TpHkCyLqHB81h1ByRnPbzsQFAc Ae5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679761198; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qLtdzZNUNvDWRCRQ9e+GAD8sIBUs/8gQPsfCU/fHYAA=; b=aW3qQICYk7qZ1RMJmTl+UfqrM3o3wLd/Fc8bLYKfHukXchuOgmEQkFrJhyNmJRu3qP Tz714YlE3QP3ux2o1Zib5RVxAj2BrN0HGNLWinMFBuSMtDNzRd02hBgg1vBjYhvOCojY u5Z7tl3zXgxN2jfsy1Sw6gtoVv+T0ugAW32Xu7SwKBewild3y87O9DmAAUvpeR0keufR M0XM26lW59FDoe0xU3gXdz/Qt3jIQlBEFM/xItwzihIwQ21VwPzjpXCh4ZM2gQ4j5IQX ugngPIGU3zGn4ChUl+bpm+TrJlNzjX4LvWcvFqmoUdT/e50QBhFfp8FPzXrbwBO1yhfE IAAA== X-Gm-Message-State: AAQBX9e6RZayHnOq68tRWLpftT6Dn1bit8AMUyzcGjJeyBTVksT2qiRC 50gA6hBG5tw4qWTCJXy0uDo= X-Google-Smtp-Source: AKy350ZrEdAuWrJ7C/YiCEBnKJ5waRCh/viX/VcEaBCLKubjVvwVMRM1gEJx1XA+KavM5VVjCuLEuw== X-Received: by 2002:a5d:69cc:0:b0:2ce:aa0e:c60b with SMTP id s12-20020a5d69cc000000b002ceaa0ec60bmr5578530wrw.53.1679761198511; Sat, 25 Mar 2023 09:19:58 -0700 (PDT) Received: from smtpclient.apple ([2a00:23c6:5484:ac01:e12d:76f0:ef75:d129]) by smtp.gmail.com with ESMTPSA id v3-20020adfe4c3000000b002cf8220cc75sm12987937wrm.24.2023.03.25.09.19.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Mar 2023 09:19:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Matthew Malcomson In-Reply-To: <83v8ipcaot.fsf@gnu.org> Date: Sat, 25 Mar 2023 16:19:57 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <36DF2B3B-8E8B-4418-8DBB-A67A1292817A@gmail.com> References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> <83v8ipcaot.fsf@gnu.org> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On 25 Mar 2023, at 11:49, Eli Zaretskii wrote: >=20 >> From: Matthew Malcomson >> Date: Fri, 24 Mar 2023 13:37:57 +0000 >>=20 >>=20 >>=20 >> I think the final state after having done the above should be: >> 1) Global value has not changed. >> 2) Local value has not changed. >>=20 >> While the observed state after the above is: >> 1) Global value has been set to `other-symbol'. >> 2) Local value has been removed. >>=20 >> - The `setq` inside the `let` sets the *global* value rather than = creating a buffer-local variable. >> - The `let` on the buffer-local version of the variable is lost. >=20 > What is the purpose of doing this? what are you trying to accomplish, > and why? >=20 I came across this when looking into that yasnippet bug I linked in my = previous email. This sequence is not performed on purpose. The let binding and kill-local-variable happen outside that plugins = control, and are unexpected. The specific context is: When yasnippet minor mode is turned on it records the =E2=80=9Coriginal=E2= =80=9D `auto-fill-function` and replaces it with its own wrapper using = `setq`. It uses the =E2=80=9Coriginal=E2=80=9D to `funcall` from the wrapper and = to resetting when yasnippet minor mode turned off. Yasnippet sets `auto-fill-function` to its wrapper using =E2=80=99setq=E2=80= =99 to ensure the value is buffer-local. AIUI the minor mode is usually turned on outside of any let binding, but = the described situation happens due to an edge-case: - `newline` let-binds `auto-fill-mode` - Visited file has changed outside of emacs, so user is queried whether = to `revert-buffer` while in `newline` - `revert-buffer` calls `normal-mode`, which runs = `kill-all-local-variables` - Later, `yasnippet-mode` is turned on and the `setq` is evaluated. N.b. The change I=E2=80=99m suggesting only means that whatever was = outside the `let` binding is kept. That implies that there would still likely be some problem edge-case in = the yasnippet code. I=E2=80=99m just raising the bug on the premise that the existing = behaviour seems likely to cause harder to debug problems that my = suggestion. I.e. once at the top-level, seeing a `setq` of a buffer-local variable = has changed the top-level global value is very surprising to me. But not seeing the effect of a `setq` because it was performed inside = some unexpected `let` binding is less surprising. So I believe that debugging unexpected behaviour due to the second would = be easier than behaviour due to the first. >> The manual for `make-variable-buffer-local` =E2=80=94 in `(elisp) = Creating Buffer-Local` =E2=80=94 does mention that if a variable is in a = `let` binding then a `setq` does not create a buffer-local version. >> That said, I=E2=80=99m guessing the intention of this behaviour is so = a `let` binding on a global variable is modified rather than bypassed by = a `setq`. >> I=E2=80=99d suggest that is not relevant to the above code since the = use of `kill-local-variable` means the `let` is effectively lost already = (e.g. it does not get =E2=80=9Creset=E2=80=9D on an unwind). >=20 > Did you also read about default-toplevel-value and > set-default-toplevel-value (in the "Default Value" node of the ELisp > manual)? Honestly I haven=E2=80=99t looked hard into how to fix the bug I was = hitting in elisp. A solution seems like it would have to answer the more general question = of what yasnippet should do if it=E2=80=99s minor-mode is turned on = while in a `let` binding of `auto-fill-mode`, and I=E2=80=99m not a = yasnippet developer. I'm reporting this on the premise that the elisp behaviour seemed = strange enough to me to ask whether it should be different. >=20 >> I=E2=80=99m not proposing this as a change, just including it for = extra context about the cause. >> I *believe* that the form of the C code around here looks like the = special case of a forwarded variable not having a buffer-local value but = having a buffer-local `let` binding could easily have been an oversight = rather than intention. >=20 > Stefan, any comments? From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Mar 2023 14:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Matthew Malcomson Cc: 62419@debbugs.gnu.org Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.167983932116917 (code B ref 62419); Sun, 26 Mar 2023 14:02:02 +0000 Received: (at 62419) by debbugs.gnu.org; 26 Mar 2023 14:02:01 +0000 Received: from localhost ([127.0.0.1]:45608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgQwb-0004Ok-84 for submit@debbugs.gnu.org; Sun, 26 Mar 2023 10:02:01 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25932) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgQwY-0004OU-8o for 62419@debbugs.gnu.org; Sun, 26 Mar 2023 10:01:59 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9C19C440B2C; Sun, 26 Mar 2023 10:01:52 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6EA594403D5; Sun, 26 Mar 2023 10:01:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1679839310; bh=UTCqmxl/1IHrZsdIhuVTxMfk1Fsc5YulL8TPgiJLrvI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=E+JcppWsdRCOgQpeWB6jo/Atgz0pTkDq6f0d6VBB0TqX7SqIhLYwg/R4VvLs+euY4 IBn5aIda6hChgm8vvn/B+/qk3AgveluNmyppFc54PqUPSsKLVHzkEXbEDuXuKsRt4t t2D22S6W8Hm8xZeluA9iHf7OBFPg5hkjz+KLqOA6ZXPGUsTxIgVpv2AtNa35xZlrYr Lxu7sJnBm/oN5u9Hf6iJxmWjFi5rpKhmgenz30E59hSFEKPxv4OVJp0L7HEjnlGyyh /mkhyX8CoHz6U8UixpwgPOnjXPJ3ETIcc1mzZbfOtVd4ne7PVaI+2wCcNp60L9PK4S olfoDfReYuTNw== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 489C91231A8; Sun, 26 Mar 2023 10:01:50 -0400 (EDT) From: Stefan Monnier In-Reply-To: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> (Matthew Malcomson's message of "Fri, 24 Mar 2023 13:37:57 +0000") Message-ID: References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> Date: Sun, 26 Mar 2023 10:01:48 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.050 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > (setq auto-fill-function 'local-symbol) > (describe-variable 'auto-fill-function) > ;; `auto-fill-function' is let-bound in the buffer scope > (let ((auto-fill-function 'temp-symbol)) > ;; Now there is no buffer-local variable for `auto-fill-function', but the > ;; `let' unwrapping info is still there. > (kill-local-variable 'auto-fill-function) > ;; Since the check in the emacs source is > ;; a) Is there a buffer-local variable. > ;; b) Is there a let-binding shadowing the current variable. > ;; Then this `setq' sets the *global* variable. > (setq auto-fill-function 'other-symbol)) > ;; Exiting the `let' has special handling to avoid resetting a local variable > ;; when the local variable was `let' bound, which means that overall the `setq' > ;; set the global variable and the `let' has been lost. AFAIK the behavior is "as intended": the `let` only affects *one* binding, either the global one or the buffer-local one. > AIUI the minor mode is usually turned on outside of any let binding, but the > described situation happens due to an edge-case: > - `newline` let-binds `auto-fill-mode` > - Visited file has changed outside of Emacs, so user is queried whether to > `revert-buffer` while in `newline` > - `revert-buffer` calls `normal-mode`, which runs `kill-all-local-variables` > - Later, `yasnippet-mode` is turned on and the `setq` is evaluated. The "`newline` let-binds `auto-fill-mode`" seems like the source of the problem :-( As for yasnippet.el, I suspect that I patch like the one below would avoid the problem. Stefan diff --git a/yasnippet.el b/yasnippet.el index 78ef38ac39..98124c7a61 100644 --- a/yasnippet.el +++ b/yasnippet.el @@ -860,10 +828,9 @@ which decides on the snippet to expand.") "Hook run when `yas-minor-mode' is turned on.") (defun yas--auto-fill-wrapper () - (when (and auto-fill-function - (not (eq auto-fill-function #'yas--auto-fill))) - (setq yas--original-auto-fill-function auto-fill-function) - (setq auto-fill-function #'yas--auto-fill))) + (when auto-fill-function ;Turning the mode ON. + (cl-assert (local-variable-p 'auto-fill-function)) + (add-function :around (local 'auto-fill-function) #'yas--auto-fill))) ;;;###autoload (define-minor-mode yas-minor-mode @@ -906,8 +873,8 @@ Key bindings: ;; auto-fill handler. (remove-hook 'post-command-hook #'yas--post-command-handler t) (remove-hook 'auto-fill-mode-hook #'yas--auto-fill-wrapper) - (when (local-variable-p 'yas--original-auto-fill-function) - (setq auto-fill-function yas--original-auto-fill-function)) + (when (local-variable-p 'auto-fill-function) + (remove-function (local 'auto-fill-function) #'yas--auto-fill)) (setq emulation-mode-map-alists (remove 'yas--direct-keymaps emulation-mode-map-alists))))) @@ -3880,7 +3847,7 @@ field start. This hook does nothing if an undo is in progress." snippet (yas--snippet-field-mirrors snippet))) (setq yas--todo-snippet-indent nil)))) -(defun yas--auto-fill () +(defun yas--auto-fill (orig-fun &rest args) ;; Preserve snippet markers during auto-fill. (let* ((orig-point (point)) (end (progn (forward-paragraph) (point))) @@ -3897,44 +3864,7 @@ field start. This hook does nothing if an undo is in progress." reoverlays)) (goto-char orig-point) (let ((yas--inhibit-overlay-hooks t)) - (if yas--original-auto-fill-function - (funcall yas--original-auto-fill-function) - ;; Shouldn't happen, gather more info about it (see #873/919). - (let ((yas--fill-fun-values `((t ,(default-value 'yas--original-auto-fill-function)))) - (fill-fun-values `((t ,(default-value 'auto-fill-function)))) - ;; Listing 2 buffers with the same value is enough - (print-length 3)) - (save-current-buffer - (dolist (buf (let ((bufs (buffer-list))) - ;; List the current buffer first. - (setq bufs (cons (current-buffer) - (remq (current-buffer) bufs))))) - (set-buffer buf) - (let* ((yf-cell (assq yas--original-auto-fill-function - yas--fill-fun-values)) - (af-cell (assq auto-fill-function fill-fun-values))) - (when (local-variable-p 'yas--original-auto-fill-function) - (if yf-cell (setcdr yf-cell (cons buf (cdr yf-cell))) - (push (list yas--original-auto-fill-function buf) yas--fill-fun-values))) - (when (local-variable-p 'auto-fill-function) - (if af-cell (setcdr af-cell (cons buf (cdr af-cell))) - (push (list auto-fill-function buf) fill-fun-values)))))) - (lwarn '(yasnippet auto-fill bug) :error - "`yas--original-auto-fill-function' unexpectedly nil in %S! Disabling auto-fill. - %S - `auto-fill-function': %S\n%s" - (current-buffer) yas--fill-fun-values fill-fun-values - (if (fboundp 'backtrace--print-frame) - (with-output-to-string - (mapc (lambda (frame) - (apply #'backtrace--print-frame frame)) - yas--watch-auto-fill-backtrace)) - "")) - ;; Try to avoid repeated triggering of this bug. - (auto-fill-mode -1) - ;; Don't pop up more than once in a session (still log though). - (defvar warning-suppress-types) ; `warnings' is autoloaded by `lwarn'. - (add-to-list 'warning-suppress-types '(yasnippet auto-fill bug))))) + (apply orig-fun args)) (save-excursion (setq end (progn (forward-paragraph) (point))) (setq beg (progn (backward-paragraph) (point)))) From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Mar 2023 14:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Matthew Malcomson Cc: 62419@debbugs.gnu.org Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.167984125720213 (code B ref 62419); Sun, 26 Mar 2023 14:35:02 +0000 Received: (at 62419) by debbugs.gnu.org; 26 Mar 2023 14:34:17 +0000 Received: from localhost ([127.0.0.1]:45660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgRRp-0005Fx-AY for submit@debbugs.gnu.org; Sun, 26 Mar 2023 10:34:17 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgRRn-0005Fj-3D for 62419@debbugs.gnu.org; Sun, 26 Mar 2023 10:34:15 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 78E67440BB1; Sun, 26 Mar 2023 10:34:08 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0E44C440B52; Sun, 26 Mar 2023 10:34:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1679841247; bh=xKwTolfeTvrZT2pPLgy5S0jzIKz/90oGmST+ETMw2gU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Bvq9Z6hpBHfveFaldtglNLGxsZijPiDjN+PGFKXdcmZEfYdgWaQz0vbAEXFiPciZM FKlcyQSY7msc1Wadl1BFfecmMVBgJbt3PyRTEak48w0s2lgjl6F6/F7j77Et8rsfvt wWIQyDxPksdME9s3uq0Yxa9lhY8LkHdSic37kvDpj2ICVRg6O6drKhzB73XtFdzBUL IS/qi2pQYJjsGDCl7RyNXwRHUDhQwjcITS4JnouD2+4huzCilXcTkl8zUJg+30gvMN MBSfyDG6MMZPnuiyWE1XsvSJSmUbByK0+nE/nJVGCLDzEOGLZOZTt3XA3v26KH/pOu 8SCzjCyQICBMA== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E06A712331D; Sun, 26 Mar 2023 10:34:06 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Sun, 26 Mar 2023 10:01:48 -0400") Message-ID: References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> Date: Sun, 26 Mar 2023 10:34:05 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.050 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > The "`newline` let-binds `auto-fill-mode`" seems like the source of the > problem :-( We could fix it with a patch like the one below (intended for `master`). Stefan diff --git a/lisp/simple.el b/lisp/simple.el index 3e50e888dad..6f0215bfb1d 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -659,7 +659,7 @@ newline (beforepos (point)) (last-command-event ?\n) ;; Don't auto-fill if we have a prefix argument. - (auto-fill-function (if arg nil auto-fill-function)) + (inhibit-auto-fill (or inhibit-auto-fill arg)) (arg (prefix-numeric-value arg)) (procsym (make-symbol "newline-postproc")) ;(bug#46326) (postproc @@ -9269,11 +9269,15 @@ default-indent-new-line ;; If we're not inside a comment, just try to indent. (t (indent-according-to-mode)))))) +(defvar inhibit-auto-fill nil + "Non-nil means to do as if `auto-fill-mode' was disabled.") + (defun internal-auto-fill () "The function called by `self-insert-command' to perform auto-filling." - (when (or (not comment-start) - (not comment-auto-fill-only-comments) - (nth 4 (syntax-ppss))) + (when (and (not inhibit-auto-fill) + (or (not comment-start) + (not comment-auto-fill-only-comments) + (nth 4 (syntax-ppss)))) (funcall auto-fill-function))) (defvar normal-auto-fill-function #'do-auto-fill From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Matthew Malcomson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Mar 2023 15:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 62419@debbugs.gnu.org Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.167984289223082 (code B ref 62419); Sun, 26 Mar 2023 15:02:02 +0000 Received: (at 62419) by debbugs.gnu.org; 26 Mar 2023 15:01:32 +0000 Received: from localhost ([127.0.0.1]:45681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgRsB-00060E-Uh for submit@debbugs.gnu.org; Sun, 26 Mar 2023 11:01:32 -0400 Received: from mail-wm1-f47.google.com ([209.85.128.47]:42914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgRsA-000600-HU for 62419@debbugs.gnu.org; Sun, 26 Mar 2023 11:01:31 -0400 Received: by mail-wm1-f47.google.com with SMTP id m6-20020a05600c3b0600b003ee6e324b19so3626578wms.1 for <62419@debbugs.gnu.org>; Sun, 26 Mar 2023 08:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679842884; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JbTYGRFp+nJ2xyM44imgHp6ov4HeWh9YgjhDC0q+Oyg=; b=hACl+wcklFJBPObc6gKPiYbdmFboM+m5t2BRisJi6oeicHbgce9nwLJ/2qE8H9Gg5e JSpTtkeoT3C31hcoIEVachtYUT/8UeDMRD2RakPzbWJjaOt52OuR5URQa9R5cMvHeErm gIzfhCsielM0BxkXUdjNwvHLOzQ6n6q/Ay5+T3ganXAvfLRqV+XGg1BK3HS2YnVSVQQ9 Pm1GnAcwYL2u8OMg95I/Jz2ZeXS7h5I98+768MNNOaXbaa2qNQbzmgIhGGTf0nFKcqjw Cygf9/7M4/He4P4zl9RmLVDnilIsvL/sjPbBUTUgH+5M5i1zvcKWW5VavzS+jUpPikNA efxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679842884; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JbTYGRFp+nJ2xyM44imgHp6ov4HeWh9YgjhDC0q+Oyg=; b=FWTrveE/90Lt4RGo4t2tdSXP2loldcj/gdXXjdawRR4xypsJ5iVOHxO2k2fPgzpl1l ZZKBKYU5Ypq6Igaj0zTqNhsWMjt486p4wc4A3MUns0TeiIWEDKT/greGxgUne4urE7QO ERMJfhi97bcg3NT+cdyPDM9qkbYMwzAQLkX3qMhcen17AjYdXVrNkoodaQsNSOuFkOK9 EaWzvr4WBqmuPDF/RBl0o2OPt4OdJMOMSE5vaciDDh73JFJ+e68+Q1UnP5gTjwDTEjrD Klwb2XGkQsOm4iSD4Cf/lJXBLql+bfj6/Pqe7k3eKfKATyAzJR+zq6SogE+h2rB5USE2 pZjA== X-Gm-Message-State: AO0yUKWCiXnC3AyrqpQVLC5Rry3vAyTINSLkL0wYlLQWo2oLgBpJVwrz v/6wSGb6f/HZfh/efg+Fe6JtsDpiSaQ+aw== X-Google-Smtp-Source: AK7set+EbR+gFkC9FeXkbyKeex2Sfwg+CXS5DfXsTAF/K//kYNxYNRRkZjCuS6tZ9oFGJCh1tC/P2g== X-Received: by 2002:a05:600c:214d:b0:3eb:39e7:3607 with SMTP id v13-20020a05600c214d00b003eb39e73607mr7116949wml.4.1679842884073; Sun, 26 Mar 2023 08:01:24 -0700 (PDT) Received: from smtpclient.apple ([2a00:23c6:5484:ac01:18a8:8215:5cbb:57b9]) by smtp.gmail.com with ESMTPSA id o39-20020a05600c512700b003edddae1068sm5896694wms.9.2023.03.26.08.01.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2023 08:01:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Matthew Malcomson In-Reply-To: Date: Sun, 26 Mar 2023 16:01:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56FDA944-04A3-4993-93BE-3E3E0F1CD227@gmail.com> References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On 26 Mar 2023, at 15:01, Stefan Monnier = wrote: >=20 >> (setq auto-fill-function 'local-symbol) >> (describe-variable 'auto-fill-function) >> ;; `auto-fill-function' is let-bound in the buffer scope >> (let ((auto-fill-function 'temp-symbol)) >> ;; Now there is no buffer-local variable for `auto-fill-function', = but the >> ;; `let' unwrapping info is still there. >> (kill-local-variable 'auto-fill-function) >> ;; Since the check in the emacs source is >> ;; a) Is there a buffer-local variable. >> ;; b) Is there a let-binding shadowing the current variable. >> ;; Then this `setq' sets the *global* variable. >> (setq auto-fill-function 'other-symbol)) >> ;; Exiting the `let' has special handling to avoid resetting a local = variable >> ;; when the local variable was `let' bound, which means that overall = the `setq' >> ;; set the global variable and the `let' has been lost. >=20 > AFAIK the behavior is "as intended": the `let` only affects *one* > binding, either the global one or the buffer-local one. >=20 Not going to push much on this since your suggested change to `newline` = would fix everything to me. But the part I think is strange is `setq` not creating a buffer-local = binding in this environment. (i.e. not to do with what `let` is affecting). The =E2=80=9Cspecial behaviour=E2=80=9D that a `setq` may act on a = global binding of an automatic buffer-local variable when inside a let = binding seems to me like the intention is to avoid =E2=80=9Cbypassing=E2=80= =9D a let on a global binding. I.e. currently the behaviour of `setq` on automatic buffer-local = variables is: - Outside `let`, always affect buffer-local (creating if = necessary) - In `let` of global binding, affect global binding. - In `let` of buffer-local binding, affect buffer-local - In `let` of buffer-local binding but where buffer-local value = has been killed, affect global value. I believe that last condition is strange and the behaviour of `setq` = would be more understandable without it. Especially since when viewed from the top-level (i.e. evaluate some lisp = which contains a `setq` of an automatic buffer-local variable and may or = may not have a `let`) the options are: - If `setq` is outside any `let`, it will affect a buffer-local = binding. - If `setq` is inside a `let` then it won=E2=80=99t be visible = once exited the `let` (i.e. it affects the binding that the `let` acted = on) - *Unless* the `let` was of a buffer-local binding and that = buffer-local binding was killed, in which case the `setq` will affect = the global binding. Either way, thanks for looking into this! Matthew From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Mar 2023 15:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Matthew Malcomson Cc: 62419@debbugs.gnu.org Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.167984381524536 (code B ref 62419); Sun, 26 Mar 2023 15:17:02 +0000 Received: (at 62419) by debbugs.gnu.org; 26 Mar 2023 15:16:55 +0000 Received: from localhost ([127.0.0.1]:45702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgS74-0006Ng-MD for submit@debbugs.gnu.org; Sun, 26 Mar 2023 11:16:55 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgS73-0006NQ-0p for 62419@debbugs.gnu.org; Sun, 26 Mar 2023 11:16:53 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A006980D1A; Sun, 26 Mar 2023 11:16:47 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 186AC80937; Sun, 26 Mar 2023 11:16:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1679843806; bh=k0Fs+dqX6KEhDAHwb6kUX0fnF2Ew+dr6niauL0PndO4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZzVMlJS8HNeq+tGtsp3rCVe0PDLhEhgqCnTbDRR3roANnDWqn4x+764GWTf/q1dlp FAxhAfqFvzKPGy2ey3iuQdcpXRA9SgbotI8h6y3lgtXUmQ23oDINefoKcPlEUHWNSi 6+zrySm4gZHTmrEzfEKgGCJvn9WgA8s1Jr8n7nCpdAannSHOr/g8alJxos0L9D9vBg CZRuGKkRJU3nhd0SNADxkwPpiY89/zxMbwMH83MXrEtHnSpD7X0WSOb21l6noablWy 27pViljFkMmhYXitMOE+maQEWJmIh/N/JvcVL7JxdHmhBSL9EggCW2ipacYqS2lnJY sHMMsLUwGh27w== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E49991201C8; Sun, 26 Mar 2023 11:16:45 -0400 (EDT) From: Stefan Monnier In-Reply-To: <56FDA944-04A3-4993-93BE-3E3E0F1CD227@gmail.com> (Matthew Malcomson's message of "Sun, 26 Mar 2023 16:01:22 +0100") Message-ID: References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> <56FDA944-04A3-4993-93BE-3E3E0F1CD227@gmail.com> Date: Sun, 26 Mar 2023 11:16:44 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.023 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >>> (setq auto-fill-function 'local-symbol) >>> (describe-variable 'auto-fill-function) >>> ;; `auto-fill-function' is let-bound in the buffer scope >>> (let ((auto-fill-function 'temp-symbol)) >>> ;; Now there is no buffer-local variable for `auto-fill-function', but the >>> ;; `let' unwrapping info is still there. >>> (kill-local-variable 'auto-fill-function) >>> ;; Since the check in the emacs source is >>> ;; a) Is there a buffer-local variable. >>> ;; b) Is there a let-binding shadowing the current variable. >>> ;; Then this `setq' sets the *global* variable. >>> (setq auto-fill-function 'other-symbol)) >>> ;; Exiting the `let' has special handling to avoid resetting a local variable >>> ;; when the local variable was `let' bound, which means that overall the `setq' >>> ;; set the global variable and the `let' has been lost. >> >> AFAIK the behavior is "as intended": the `let` only affects *one* >> binding, either the global one or the buffer-local one. >> > > Not going to push much on this since your suggested change to > `newline` would fix everything to me. But the part I think is strange > is `setq` not creating a buffer-local binding in this environment. Hmm... maybe you're right that the (setq auto-fill-function 'other-symbol) shouldn't set the global variable but the local one. It might be a bug in how we check whether there's a let-binding that should make us refrain from obeying the "automatically set buffer-locally". Good point. I'll have to take a closer look. > I.e. currently the behaviour of `setq` on automatic buffer-local variables is: > - Outside `let`, always affect buffer-local (creating if necessary) > - In `let` of global binding, affect global binding. > - In `let` of buffer-local binding, affect buffer-local > - In `let` of buffer-local binding but where buffer-local value has > been killed, affect global value. > > I believe that last condition is strange and the behaviour of `setq` would > be more understandable without it. Agreed. Stefan From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Mar 2023 15:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Matthew Malcomson Cc: 62419@debbugs.gnu.org Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.167984465525969 (code B ref 62419); Sun, 26 Mar 2023 15:31:02 +0000 Received: (at 62419) by debbugs.gnu.org; 26 Mar 2023 15:30:55 +0000 Received: from localhost ([127.0.0.1]:45718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgSKc-0006kn-UL for submit@debbugs.gnu.org; Sun, 26 Mar 2023 11:30:55 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40757) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgSKb-0006kZ-4M for 62419@debbugs.gnu.org; Sun, 26 Mar 2023 11:30:53 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 65E26440C2F; Sun, 26 Mar 2023 11:30:47 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EC3F94402ED; Sun, 26 Mar 2023 11:30:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1679844646; bh=U+y/HUKm49SayQq04tWkxJBD9f+UVkELAwnJyqqr1rY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=C2a7NGTVF7+krHHKJQ2c+nW4iulZsd5z1dQGGDOVxPRR8Hc3saeFK8Z2c3dIs/HEP I6VAevYseQ6H9CyzXBpxblDa23ZOP7s95DGLf+V93uV/nOze9ZIBDPEeBvI87L6+7P k9/yciH4ATPkZrwYG4ykYfU6IG6rywwzQ8p0OegChphoCdrNFekchhqgiAG4Cmzkpp QghvHLmd19D21A50qm0ThAdJMwYkdvJE6iH89+bqXxcGlNW8ynVCyPupwNmAaEDEeS am4Sv5KJpks8n+QDV6LzmJnxy02tyMhYtK38W0JtG7tPAF9WztmM0CbWBKzTp7FH32 ksoiJVaAt/BPA== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A5D481232D9; Sun, 26 Mar 2023 11:30:45 -0400 (EDT) From: Stefan Monnier In-Reply-To: <56FDA944-04A3-4993-93BE-3E3E0F1CD227@gmail.com> (Matthew Malcomson's message of "Sun, 26 Mar 2023 16:01:22 +0100") Message-ID: References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> <56FDA944-04A3-4993-93BE-3E3E0F1CD227@gmail.com> Date: Sun, 26 Mar 2023 11:30:43 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.799 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain KAM_STOCKGEN 1.5 Email Contains Generic Pump & Dump Stock Tip X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I.e. currently the behaviour of `setq` on automatic buffer-local variables is: > - Outside `let`, always affect buffer-local (creating if necessary) > - In `let` of global binding, affect global binding. > - In `let` of buffer-local binding, affect buffer-local > - In `let` of buffer-local binding but where buffer-local value has > been killed, affect global value. > > I believe that last condition is strange and the behaviour of `setq` would > be more understandable without it. I think the patch below would fix this corner case. Stefan diff --git a/src/eval.c b/src/eval.c index ef7ca33f834..82ada40b309 100644 --- a/src/eval.c +++ b/src/eval.c @@ -3364,7 +3364,7 @@ DEFUN ("fetch-bytecode", Ffetch_bytecode, Sfetch_bytecode, return object; } -/* Return true if SYMBOL currently has a let-binding +/* Return true if SYMBOL's default currently has a let-binding which was made in the buffer that is now current. */ bool @@ -3379,6 +3379,7 @@ let_shadows_buffer_binding_p (struct Lisp_Symbol *symbol) struct Lisp_Symbol *let_bound_symbol = XSYMBOL (specpdl_symbol (p)); eassert (let_bound_symbol->u.s.redirect != SYMBOL_VARALIAS); if (symbol == let_bound_symbol + && !p->kind == SPECPDL_LET_LOCAL /* bug#62419 */ && EQ (specpdl_where (p), buf)) return 1; } From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Matthew Malcomson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Mar 2023 10:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 62419@debbugs.gnu.org Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.168008740230635 (code B ref 62419); Wed, 29 Mar 2023 10:57:02 +0000 Received: (at 62419) by debbugs.gnu.org; 29 Mar 2023 10:56:42 +0000 Received: from localhost ([127.0.0.1]:51371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phTTt-0007y3-O8 for submit@debbugs.gnu.org; Wed, 29 Mar 2023 06:56:42 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:40633) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phTTr-0007xm-IT for 62419@debbugs.gnu.org; Wed, 29 Mar 2023 06:56:40 -0400 Received: by mail-wr1-f49.google.com with SMTP id t4so9961964wra.7 for <62419@debbugs.gnu.org>; Wed, 29 Mar 2023 03:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680087393; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uHzW7SfFikrT6rYSSBKZeoyDTVW+1gtqS1gZPg6wlWs=; b=LmtS7kMW9aNvYSmOb9gwfBeljd151A7klTH+1YuwDtPg9hs6VOLUMhY94AM7TtvE+T uuTkbOMGoVrX/HyEpEwrdLJAW52XTMvP+yGGVper5pWHS3ds23NUeUJDcOrLZlrnO3Zw Ba+6k2owcERpRES8Ry20RwMnQRWRTVNAzF/UVdeAhlpI6aKiiDmlPyIOj23lY8rebMM+ AEJrnqS/ufvDnB7WESZlGq9rvhYmXy8iWscc39+4QI9xvQjL1YCwhPKw6HvVGDbMuAEG RAOCUVGNZpXJITjjNGcd3MEGCAUo9YtKU2dikPWPvSw09cvzVIcykGUHF8bqtVNr1m4w WPNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680087393; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uHzW7SfFikrT6rYSSBKZeoyDTVW+1gtqS1gZPg6wlWs=; b=t2I5HzRKspGjKNMmdEn+mB01xrmhMQnIax7hmT+xz89aSkK7Zp34fucuE6K1XI6pzZ SUOYDibZLVnIxg7q48ehn9G9M8RQgS1V9OVaqe8DAKiKsn96f++lIUZJeOpkuVIs+V9U b+w8X23C5y+tRVaPAsAi/YpnLT9/BCKhJylMV36XLVpDsdMuRppfyXBzOlHmFZasLSzT J8FgnReWPpcKrcCAtrwqiPc3kXZ8MK7Rdo8zCyhTLyr/z2u2vSwQP2G93rHaRjIUfTkd PIJm0M/jAoO0Ht0TL555l+s0FLqXBdnjg1vdG8QlL9KkqkRZv2SQvRSM+g/6ofedQkM8 6+UQ== X-Gm-Message-State: AAQBX9f33V7TGaVO17gNwm7vDjvGNe1QZpNUhSc9qQi49YF/clB5D/RL PgoNO1eo/PA4R4d1VkaCgfA= X-Google-Smtp-Source: AKy350aDoFP/EawXKzwg72/YAVIvbgxb5bwFRj49WO+ehQntAtOVohkJDjQ6VafElb2WjPl8qJfyEw== X-Received: by 2002:a5d:4d51:0:b0:2d2:20ed:b572 with SMTP id a17-20020a5d4d51000000b002d220edb572mr14083994wru.69.1680087393526; Wed, 29 Mar 2023 03:56:33 -0700 (PDT) Received: from smtpclient.apple ([2a00:23c6:5484:ac01:18a8:8215:5cbb:57b9]) by smtp.gmail.com with ESMTPSA id t14-20020a05600001ce00b002da76acfee1sm17623024wrx.28.2023.03.29.03.56.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2023 03:56:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Matthew Malcomson In-Reply-To: Date: Wed, 29 Mar 2023 11:56:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> <56FDA944-04A3-4993-93BE-3E3E0F1CD227@gmail.com> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Thanks! Just for the record I=E2=80=99ve been running using essentially this = patch (but with !=3D) since you suggested it and have not had any = problems. FWIW I also think the change to avoid `let` binding `auto-fill-function` = in `normal-mode` is good. Regards, Matthew > On 26 Mar 2023, at 16:30, Stefan Monnier = wrote: >=20 >> I.e. currently the behaviour of `setq` on automatic buffer-local = variables is: >> - Outside `let`, always affect buffer-local (creating if = necessary) >> - In `let` of global binding, affect global binding. >> - In `let` of buffer-local binding, affect buffer-local >> - In `let` of buffer-local binding but where buffer-local value = has >> been killed, affect global value. >>=20 >> I believe that last condition is strange and the behaviour of `setq` = would >> be more understandable without it. >=20 > I think the patch below would fix this corner case. >=20 >=20 > Stefan >=20 >=20 > diff --git a/src/eval.c b/src/eval.c > index ef7ca33f834..82ada40b309 100644 > --- a/src/eval.c > +++ b/src/eval.c > @@ -3364,7 +3364,7 @@ DEFUN ("fetch-bytecode", Ffetch_bytecode, = Sfetch_bytecode, > return object; > } >=20 > -/* Return true if SYMBOL currently has a let-binding > +/* Return true if SYMBOL's default currently has a let-binding > which was made in the buffer that is now current. */ >=20 > bool > @@ -3379,6 +3379,7 @@ let_shadows_buffer_binding_p (struct Lisp_Symbol = *symbol) > struct Lisp_Symbol *let_bound_symbol =3D XSYMBOL (specpdl_symbol = (p)); > eassert (let_bound_symbol->u.s.redirect !=3D SYMBOL_VARALIAS); > if (symbol =3D=3D let_bound_symbol > + && !p->kind =3D=3D SPECPDL_LET_LOCAL /* bug#62419 */ > && EQ (specpdl_where (p), buf)) > return 1; > } >=20 From unknown Sun Aug 17 22:02:31 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Apr 2023 21:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Matthew Malcomson Cc: 62419@debbugs.gnu.org Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.168047254916201 (code B ref 62419); Sun, 02 Apr 2023 21:56:02 +0000 Received: (at 62419) by debbugs.gnu.org; 2 Apr 2023 21:55:49 +0000 Received: from localhost ([127.0.0.1]:42881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj5fx-0004DF-4n for submit@debbugs.gnu.org; Sun, 02 Apr 2023 17:55:49 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41893) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj5fs-0004Cx-Pe for 62419@debbugs.gnu.org; Sun, 02 Apr 2023 17:55:47 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0517E442BBA; Sun, 2 Apr 2023 17:55:39 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id AB2D4442A62; Sun, 2 Apr 2023 17:55:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1680472537; bh=2lsqvtij4nDxWWvw3STuUvpAFKeZCslA+fUEwaOwurI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lmhJGLwCQCos2gX2N12Fd3WEatjsWZsiA88f6sDKzrmYU0stq1o33fXoqdsYvSuX2 pIQjpkuK4YvWUXJ9S8m0HxF/mKvXSYZIgU2ztKBL967NNDqmmHKaqlWZw6ZUWn28wF AvR7Q3wK0ZSFzv+SUxQTuB2eToj2F90/J+lHzq/0dWyYAEsFmb6pnNGXsMbuZ2xj9D T3nJ4tDRcIRq2lpi00e1FEwydB79fFJuNE+Cq7xxyTipxLAHHBi17MBk8WiLzqAxj9 e9pCm9K/UFHJoaHvOK18gcEndMx/jFnYQ8eTIDzdvG5M3p29YqnoemiDZD8pg/zOSm VlDjUJaS0iV1g== Received: from pastel (unknown [45.72.217.176]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 75ACB123356; Sun, 2 Apr 2023 17:55:37 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Matthew Malcomson's message of "Wed, 29 Mar 2023 11:56:32 +0100") Message-ID: References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> <56FDA944-04A3-4993-93BE-3E3E0F1CD227@gmail.com> Date: Sun, 02 Apr 2023 17:55:36 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.008 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Just for the record I=E2=80=99ve been running using essentially this patc= h (but > with !=3D) since you suggested it and have not had any problems. Thanks for confirming it fixes the problem for you. I pushed it to `master` (doesn't seem "obviously safe" enough for `emacs-29= `). > FWIW I also think the change to avoid `let` binding > `auto-fill-function` in `normal-mode` is good. I also pushed it to `master`. Stefan From unknown Sun Aug 17 22:02:31 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Matthew Malcomson Subject: bug#62419: closed (Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable) Message-ID: References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> X-Gnu-PR-Message: they-closed 62419 X-Gnu-PR-Package: emacs Reply-To: 62419@debbugs.gnu.org Date: Tue, 12 Sep 2023 00:01:04 +0000 Content-Type: multipart/mixed; boundary="----------=_1694476864-23570-1" This is a multi-part message in MIME format... ------------=_1694476864-23570-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 62419@debbugs.gnu.org. --=20 62419: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D62419 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1694476864-23570-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 62419-done) by debbugs.gnu.org; 12 Sep 2023 00:01:02 +0000 Received: from localhost ([127.0.0.1]:55289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfqpx-00065i-CW for submit@debbugs.gnu.org; Mon, 11 Sep 2023 20:01:01 -0400 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:60687) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfqpu-0005qU-Sl for 62419-done@debbugs.gnu.org; Mon, 11 Sep 2023 20:00:59 -0400 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2bcb89b476bso85370031fa.1 for <62419-done@debbugs.gnu.org>; Mon, 11 Sep 2023 17:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694476849; x=1695081649; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=OLRGAHw6FbmNI4ddbOX6GR0i+FnG1fqaMNpS3ErDcXU=; b=P6DqOJaKFGVhSpO+UINkHxeQSxTfuEgJdJ8OhXGR6CZTwR5q/4msVMTeRxm4Lxekx4 Fb4hN2N/JStGJkGUYHM9NcA6hBRY9b57i1mUNY+mU8qyianQGgTD3XiPzv80p0jNrx1g eqiCZ2+k2HEv4QqjugBPGTjnuCpxbwCPciGqqgl8Y1IX60gEEgvf52DX8K/ht84KGsXB v34LwzvihRjfDB5TlggUQhOJ1PTrMMcn8vbqMXbCjq4/wGgwDgX/PWFHkDlUcEBZMONE GcGBY4z70hB9IgqJ2O+EE/Qz2SGaL2DiAjWrydPr/YWFYz0/JYF6ovGh0DkW0IIi+QnJ k+7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694476849; x=1695081649; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=OLRGAHw6FbmNI4ddbOX6GR0i+FnG1fqaMNpS3ErDcXU=; b=CQfvo4vZ3mX80nI6x8NY5v2YyDpuJelMJC4D8U81tsPw6nAAC04e8jYz0O94/lkRNp UmUGkxvh3jCbFtppNiyYQQ2T27H+iWOMlshUeUqBeoGkerOcHRutfHxsFMdG9reHr60i zWMZjBxvj/MSf1zqbY/ap/HtXGkzvY6tXYmrbyK/tiFqWnm9ZXIwfrMnu3GcVk6XG2pe k/QwLxPfkiUmunLjbYtJd+fSmH++VwFpf/sQFXZvnoRnMoFXhI8dOWOW9SML6+peaI6R 7j4DJPbP5q2t+gGA3dZA0XKmxVFi2S0UvZ3mQyrmCoPM/q+0p9XBv+6J65EvCHcx2gGc vL9w== X-Gm-Message-State: AOJu0YwdfAil6ucdqxxcL383dg6dTDJ4nS1o8Ac7v/I1zfjPWSTV9ewN nOBCrXo4ZWbFA58ugLgJyK6kLW8ZDShXq/MB3hQ= X-Google-Smtp-Source: AGHT+IHYSs8U3U2bB8480g8OBIlPlPZ/glNs/p8/Iscv62t7fc8Uwj6NjMsINBiBW99utUCP6UktEK0LtE2T3Qm/INg= X-Received: by 2002:a05:651c:203:b0:2bc:f439:b5a5 with SMTP id y3-20020a05651c020300b002bcf439b5a5mr9317813ljn.14.1694476848607; Mon, 11 Sep 2023 17:00:48 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 11 Sep 2023 17:00:48 -0700 From: Stefan Kangas In-Reply-To: (Stefan Monnier's message of "Sun, 02 Apr 2023 17:55:36 -0400") References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> <56FDA944-04A3-4993-93BE-3E3E0F1CD227@gmail.com> MIME-Version: 1.0 Date: Mon, 11 Sep 2023 17:00:48 -0700 Message-ID: Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable To: Stefan Monnier Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62419-done Cc: Matthew Malcomson , 62419-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> Just for the record I=E2=80=99ve been running using essentially this pat= ch (but >> with !=3D) since you suggested it and have not had any problems. > > Thanks for confirming it fixes the problem for you. > I pushed it to `master` (doesn't seem "obviously safe" enough for `emacs-= 29`). > >> FWIW I also think the change to avoid `let` binding >> `auto-fill-function` in `normal-mode` is good. > > I also pushed it to `master`. It seems like this issue was fixed, but it was left open in the bug tracker. I'm therefore closing it now. Please remember to close bug reports when they are fixed. ------------=_1694476864-23570-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 24 Mar 2023 13:41:33 +0000 Received: from localhost ([127.0.0.1]:40031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfhfg-0001m6-I2 for submit@debbugs.gnu.org; Fri, 24 Mar 2023 09:41:32 -0400 Received: from [209.51.188.17] (port=56186 helo=lists.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfhfc-0001lm-5a for submit@debbugs.gnu.org; Fri, 24 Mar 2023 09:41:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pfhfV-0001wD-UA for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 09:41:21 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pfhdG-000342-NJ for bug-gnu-emacs@gnu.org; Fri, 24 Mar 2023 09:41:21 -0400 Received: by mail-wr1-f41.google.com with SMTP id h17so1822234wrt.8 for ; Fri, 24 Mar 2023 06:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679665078; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=R0pgfQltGADi4VTZQwQMiledUMehW6Bz3jyY7RfNqYU=; b=btsewsi73MraonH4bJDkTR5DKwGDKKLuWECwkiD72RWpNuzxoC+j5zbIpQhqcqhMXa SAW0APbVrZCK6jet81qq4Qn7roDwSlgtDY4pKrm47jIGn/XhDJUhIXF7R3n95CpuYE+p e3RlujuJRJUZz6yYngFEfhVaUNRfkVRys1tOBebrqnWGUgtBQd+s0Zi6Y7rT+0R+vhy/ s3pDpx+T3F/q+xEUEC9fHR3KCQhrCn2mUT31qRrCbH5HvSNSAW/Df5iYGJIIM7kPKXT2 GxZ7Amv+B8xx32T+h88zH3Az+0oYQQLS1TQ3ge/bgSlmkcIUZOfDP8unij5XS+THrh0h fjqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679665078; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=R0pgfQltGADi4VTZQwQMiledUMehW6Bz3jyY7RfNqYU=; b=YIZ+T2nubY8WIqaSEQRu9Lfi7GjgroPVrP+vw5duNuQ6tFtGDRG8mEa7WMLoUopVJx ndxQueIdelxBsE0LM2zALSXcbt7U+HTgfZOZkbRFRD4y0py7jhjG9ZxA83n+sRM4z0yF yD5HiC++QE6yFPg52BfeC0QyThT3x4QAR+e2o+sBJj+eQDdgDbKr4T2w3rChuO+bFsz0 U2AM/sCAxYXRhQbitEuLqnWYh797GmecrQJYXcJyMWfBcAUywnorDOgNNF7piZvRZ4tI FHBdH7Amk9v/KIXzFq3+/Lf8u7agPmPxDkBVC2eigrkATgF+soL30sOqxpiVRv7H77Ie OmDQ== X-Gm-Message-State: AAQBX9eqLcfU0YByzPZ1johxEr7Th2baFSLIqGtN4NXp2Bu/s5o5HaZ8 e3v40Usy1IA7EQhnkyvv6ICc2uHjnAM= X-Google-Smtp-Source: AKy350ZkFi1qtzKFks6NMK0DxYAZLNX7q2rZRjWdn/NHqskHVg7UOQV+EMQ4yXUNI1EsJoxUlNvugg== X-Received: by 2002:adf:e6ca:0:b0:2ce:adff:61fc with SMTP id y10-20020adfe6ca000000b002ceadff61fcmr2192722wrm.37.1679665078511; Fri, 24 Mar 2023 06:37:58 -0700 (PDT) Received: from smtpclient.apple ([2a00:23c6:5484:ac01:e12d:76f0:ef75:d129]) by smtp.gmail.com with ESMTPSA id p14-20020a5d48ce000000b002d45575643esm16390512wrs.43.2023.03.24.06.37.57 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Mar 2023 06:37:57 -0700 (PDT) From: Matthew Malcomson Content-Type: multipart/mixed; boundary="Apple-Mail=_0BB9BE86-326B-47CF-A415-8D41F45FD27A" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Message-Id: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> Date: Fri, 24 Mar 2023 13:37:57 +0000 To: bug-gnu-emacs@gnu.org X-Mailer: Apple Mail (2.3693.60.0.1.1) Received-SPF: pass client-ip=209.85.221.41; envelope-from=hardenedapple@gmail.com; helo=mail-wr1-f41.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.1 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) --Apple-Mail=_0BB9BE86-326B-47CF-A415-8D41F45FD27A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I=E2=80=99m inlining some elisp which has behaviour I find unintuitive. To view the bug I would run each top-level form with C-x C-e in turn in = an elisp buffer. This behaviour may be expected =E2=80=94 the manual mentions something = related =E2=80=94 but I believe this is an unintended edge-case. N.b. the use of `auto-fill-function=E2=80=99 is just for a variable = which turns buffer-local when set, not as anything related to this = particular symbol. FWIW I believe this behaviour to be the root cause of = https://github.com/joaotavora/yasnippet/issues/919 (which was closed due = to not being able to reproduce it). =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 ;; Ensure that `auto-fill-function' has a buffer-local version and a = global ;; version. (setq auto-fill-function 'local-symbol) (describe-variable 'auto-fill-function) ;; `auto-fill-function' is let-bound in the buffer scope (let ((auto-fill-function 'temp-symbol)) ;; Now there is no buffer-local variable for `auto-fill-function', but = the ;; `let' unwrapping info is still there. (kill-local-variable 'auto-fill-function) ;; Since the check in the emacs source is ;; a) Is there a buffer-local variable. ;; b) Is there a let-binding shadowing the current variable. ;; Then this `setq' sets the *global* variable. (setq auto-fill-function 'other-symbol)) ;; Exiting the `let' has special handling to avoid resetting a local = variable ;; when the local variable was `let' bound, which means that overall the = `setq' ;; set the global variable and the `let' has been lost. (describe-variable 'auto-fill-function) =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 I think the final state after having done the above should be: 1) Global value has not changed. 2) Local value has not changed. While the observed state after the above is: 1) Global value has been set to `other-symbol'. 2) Local value has been removed. - The `setq` inside the `let` sets the *global* value rather than = creating a buffer-local variable. - The `let` on the buffer-local version of the variable is lost. The manual for `make-variable-buffer-local` =E2=80=94 in `(elisp) = Creating Buffer-Local` =E2=80=94 does mention that if a variable is in a = `let` binding then a `setq` does not create a buffer-local version. That said, I=E2=80=99m guessing the intention of this behaviour is so a = `let` binding on a global variable is modified rather than bypassed by a = `setq`. I=E2=80=99d suggest that is not relevant to the above code since the use = of `kill-local-variable` means the `let` is effectively lost already = (e.g. it does not get =E2=80=9Creset=E2=80=9D on an unwind). I=E2=80=99m attaching the source code hack that I=E2=80=99ve started = using to work around this. I=E2=80=99m not proposing this as a change, just including it for extra = context about the cause. I *believe* that the form of the C code around here looks like the = special case of a forwarded variable not having a buffer-local value but = having a buffer-local `let` binding could easily have been an oversight = rather than intention. (N.b. for this hack I guessed the meanings of the `let` enum values). --Apple-Mail=_0BB9BE86-326B-47CF-A415-8D41F45FD27A Content-Disposition: attachment; filename=emacs-patch.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="emacs-patch.diff" Content-Transfer-Encoding: 7bit diff --git a/src/data.c b/src/data.c index 57205d8..af427ea 100644 --- a/src/data.c +++ b/src/data.c @@ -1607,7 +1607,7 @@ set_internal (Lisp_Object symbol, Lisp_Object newval, Lisp_Object where, if (idx > 0 && bindflag == SET_INTERNAL_SET && !PER_BUFFER_VALUE_P (buf, idx)) { - if (let_shadows_buffer_binding_p (sym)) + if (let_shadows_buffer_binding_p_and_is_global (sym)) set_default_internal (symbol, newval, bindflag); else SET_PER_BUFFER_VALUE_P (buf, idx, 1); diff --git a/src/eval.c b/src/eval.c index d002e81..9200d71 100644 --- a/src/eval.c +++ b/src/eval.c @@ -3491,6 +3491,25 @@ let_shadows_buffer_binding_p (struct Lisp_Symbol *symbol) return 0; } +bool +let_shadows_buffer_binding_p_and_is_global (struct Lisp_Symbol *symbol) +{ + union specbinding *p; + Lisp_Object buf = Fcurrent_buffer (); + + for (p = specpdl_ptr; p > specpdl; ) + if ((--p)->kind == SPECPDL_LET_DEFAULT) + { + struct Lisp_Symbol *let_bound_symbol = XSYMBOL (specpdl_symbol (p)); + eassert (let_bound_symbol->u.s.redirect != SYMBOL_VARALIAS); + if (symbol == let_bound_symbol + && EQ (specpdl_where (p), buf)) + return 1; + } + + return 0; +} + static void do_specbind (struct Lisp_Symbol *sym, union specbinding *bind, Lisp_Object value, enum Set_Internal_Bind bindflag) diff --git a/src/lisp.h b/src/lisp.h index 0cad97c..0a296cd 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -4221,6 +4221,7 @@ extern void mark_specpdl (union specbinding *first, union specbinding *ptr); extern void get_backtrace (Lisp_Object array); Lisp_Object backtrace_top_function (void); extern bool let_shadows_buffer_binding_p (struct Lisp_Symbol *symbol); +extern bool let_shadows_buffer_binding_p_and_is_global (struct Lisp_Symbol *symbol); /* Defined in unexmacosx.c. */ #if defined DARWIN_OS && defined HAVE_UNEXEC --Apple-Mail=_0BB9BE86-326B-47CF-A415-8D41F45FD27A-- ------------=_1694476864-23570-1--