From unknown Sat Aug 16 21:13:03 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#62419 <62419@debbugs.gnu.org> To: bug#62419 <62419@debbugs.gnu.org> Subject: Status: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Reply-To: bug#62419 <62419@debbugs.gnu.org> Date: Sun, 17 Aug 2025 04:13:03 +0000 retitle 62419 28.2; Elisp let-bound buffer-local variable and kill-local-va= riable reassign 62419 emacs submitter 62419 Matthew Malcomson severity 62419 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 24 09:41:32 2023 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-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 25 07:54:36 2023 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 To: Matthew Malcomson , Stefan Monnier In-Reply-To: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> (message from Matthew Malcomson on Fri, 24 Mar 2023 13:37:57 +0000) Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable 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-Debbugs-Envelope-To: 62419 Cc: 62419@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: -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 debbugs-submit-bounces@debbugs.gnu.org Sat Mar 25 12:20:07 2023 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\)) Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable 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> To: Eli Zaretskii X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62419 Cc: 62419@debbugs.gnu.org, Stefan Monnier 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 debbugs-submit-bounces@debbugs.gnu.org Sun Mar 26 10:02:01 2023 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 To: Matthew Malcomson Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable 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-Debbugs-Envelope-To: 62419 Cc: 62419@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: -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 debbugs-submit-bounces@debbugs.gnu.org Sun Mar 26 10:34:17 2023 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 To: Matthew Malcomson Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable 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-Debbugs-Envelope-To: 62419 Cc: 62419@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: -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 debbugs-submit-bounces@debbugs.gnu.org Sun Mar 26 11:01:32 2023 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\)) Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable 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> To: Stefan Monnier X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62419 Cc: 62419@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 (-) > 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 debbugs-submit-bounces@debbugs.gnu.org Sun Mar 26 11:16:55 2023 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 To: Matthew Malcomson Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable 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-Debbugs-Envelope-To: 62419 Cc: 62419@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: -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 debbugs-submit-bounces@debbugs.gnu.org Sun Mar 26 11:30:55 2023 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 To: Matthew Malcomson Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable 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-Debbugs-Envelope-To: 62419 Cc: 62419@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: -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 debbugs-submit-bounces@debbugs.gnu.org Wed Mar 29 06:56:42 2023 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\)) Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable 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> To: Stefan Monnier X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62419 Cc: 62419@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 (-) 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 debbugs-submit-bounces@debbugs.gnu.org Sun Apr 02 17:55:49 2023 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 To: Matthew Malcomson Subject: Re: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable 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-Debbugs-Envelope-To: 62419 Cc: 62419@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: -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 debbugs-submit-bounces@debbugs.gnu.org Mon Sep 11 20:01:01 2023 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. From unknown Sat Aug 16 21:13:03 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 10 Oct 2023 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator