From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Matthew Malcomson Newsgroups: gmane.emacs.bugs Subject: bug#62419: 28.2; Elisp let-bound buffer-local variable and kill-local-variable Date: Sat, 25 Mar 2023 16:19:57 +0000 Message-ID: <36DF2B3B-8E8B-4418-8DBB-A67A1292817A@gmail.com> References: <19A857D6-D071-44DE-AF89-539A563FD782@gmail.com> <83v8ipcaot.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11224"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62419@debbugs.gnu.org, Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 25 17:38:08 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pg6u7-0002cT-7l for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Mar 2023 17:38:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pg6tE-0001Hq-9j; Sat, 25 Mar 2023 12:37:12 -0400 Original-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 1pg6tA-0001Go-1A for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2023 12:37:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pg6t9-0000Lo-BE for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2023 12:37:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pg6da-0003HN-MN for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2023 12:21:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 62419-submit@debbugs.gnu.org id=B62419.167976120712454 (code B ref 62419); Sat, 25 Mar 2023 16:21:02 +0000 Original-Received: (at 62419) by debbugs.gnu.org; 25 Mar 2023 16:20:07 +0000 Original-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 Original-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 Original-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) Original-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) In-Reply-To: <83v8ipcaot.fsf@gnu.org> X-Mailer: Apple Mail (2.3693.60.0.1.1) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:258599 Archived-At: > 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?