From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#65209: 30.0.50; Unexpected behaviour of setq-local Date: Sat, 26 Aug 2023 04:09:11 +0200 Message-ID: <87h6om8shk.fsf@web.de> References: <87msyu2tmm.fsf@web.de> <80D7C281-C3DD-4DCA-9B14-1569E849CBC7@gmail.com> <87wmxqqq7d.fsf@web.de> <83350exl6h.fsf@gnu.org> <87wmxnojrb.fsf@web.de> <83msyjtkeo.fsf@gnu.org> <871qfu4dyx.fsf@web.de> <83fs4arnr1.fsf@gnu.org> <87pm3dnt9j.fsf@web.de> <83msyhqajo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38324"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: gerd.moellmann@gmail.com, 65209@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 26 04:10:16 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 1qZikh-0009mU-N7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 26 Aug 2023 04:10:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qZikQ-0003Ka-Ge; Fri, 25 Aug 2023 22:09:58 -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 1qZikP-0003De-Ff for bug-gnu-emacs@gnu.org; Fri, 25 Aug 2023 22:09:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qZikP-0002uk-7n for bug-gnu-emacs@gnu.org; Fri, 25 Aug 2023 22:09:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qZikT-000201-NU for bug-gnu-emacs@gnu.org; Fri, 25 Aug 2023 22:10:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 26 Aug 2023 02:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65209 X-GNU-PR-Package: emacs Original-Received: via spool by 65209-submit@debbugs.gnu.org id=B65209.16930157747642 (code B ref 65209); Sat, 26 Aug 2023 02:10:01 +0000 Original-Received: (at 65209) by debbugs.gnu.org; 26 Aug 2023 02:09:34 +0000 Original-Received: from localhost ([127.0.0.1]:41284 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZik1-0001zC-KO for submit@debbugs.gnu.org; Fri, 25 Aug 2023 22:09:33 -0400 Original-Received: from mout.web.de ([217.72.192.78]:35131) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZijw-0001yw-Vl for 65209@debbugs.gnu.org; Fri, 25 Aug 2023 22:09:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1693015753; x=1693620553; i=michael_heerdegen@web.de; bh=TunmcmYMntCat7L6sCV7c5r/kkk2Tl1vutW8CFQ7Z+I=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=U+SsyLDpP1i2EVwiBnKUzATJAfNuLJm1n9cl6ft4cI+rcMU3IyHDO5UsBBq++R0gqOJt/M4 SKrYtJRMBMQ9i4rNM0i7D1L2V2CPe70AxPmb0hv22duu/l3eCktTF9LMRqHn0qfrV2P87eYjE Z3gipuGo6qIS4jQ3EkzmlOgo7d7E1+2TUZPiELX2z98DDzGUCcvmoqehvHdlfPjzKbncrYl5q kokXtjAzMWHmtLtxhJHD4Ff3AYk9pwFS9xbt4MgWKBc2mcfWSd0n4UJeU8/oL94sf98pphW19 iLhIqJv1xsohs6PUr+a8D8Dr1gjra47uE2+rV6qWNd3DgR9o0X8g== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([84.60.174.218]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1Mft7j-1q2YmO0V4b-00gIoa; Sat, 26 Aug 2023 04:09:13 +0200 In-Reply-To: <83msyhqajo.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 24 Aug 2023 08:22:35 +0300") X-Provags-ID: V03:K1:nRic3IvaHyDjSNxHGQyZgsUFwfX3UR1qAQ53bMFYRZ6Sj7YK788 Qf4CLruUhTTAcRYCzKQf6/cukPZgiAfQil0EVFcvijZc9Ym/59MKBeV9hRBd676l7dP0NM4 D0ymvGQYeCz0gNvmcMweK3/AuI1aEIZto+0/BQgir5cBxaIUm7d42pe+5CXQsWzP5gWIMDd 2fIGwjbHk6UvlbdmhqaOA== UI-OutboundReport: notjunk:1;M01:P0:R7bzqHLbf+U=;wK+q+2ZgQd1TjtcVtcSEEI4P0yP 9fIDJeKURPBE4QB0UkCRg+pi1caRiYxr1iBU0jZQuQAQBQzBxkycBoqulXBhPbcFDQWNG/aLR ldKAsjZQEU+BHcqMSLwFS58MI3ePd3kYhUEdLcHvZ3ZzwrQbFWtCn6y8DnDrs803IBcvwN35J cHcsBZuYYQWFmFgXN+0rGZK60AcemkhA+Sxnv25yjRSbZ1q28UbwCXRnSscFMWUiOvKB0nZD2 Ppe2yqh3eHdK6txzlcOBJBufU3D+gQOtPAbuSkw7suFOEK5YljeY+zAgq5hwVkyzB7GsSp7KG wqD3DvR18x9/n7hCGR7Hvsw3VftR4BqJco7qdH53EyFXAt5yMBigkHGVgpDKHG9cv7L5K2TzL KFiacszAcw19FiS4dMo7wL3ZEZfgMF8p+On38AL+av1cX9G4vEzp8+5jNaNcn+BtemnI3wN8L dvs70L7vJlbOwonamXfYs35BIizIVSW9s6S0d5YEu3DRfhnSL1xomT/MWI+EYTfCihBtdBW5S xJrr0k2GUhCwmOdIYjy1cq9Tv6DkUrMNQDu5+TyR0zV+qit29bGMugXi+MzFO8Wz/7wmyGhUw IzrxadcewwL1ypofyKX5FgQpu+Ex8VH6yq1d2Imcs/RJpgblrIvOvaGzU20FW/2aBiW7B6cH9 lkbldVtq2Df+OHbyH1GbIixLAEf7TaSeXVX0qaq+fVkLRb20uCZQ0WHXuixnHN6FXAZxfbeHz hsrYvCwa9LZ7B4AlKpG/0m3HcWsamfKIB9oPKkPVK+uzgc2ngnJ7e2vQwqLIVI0xEKhI3VNO 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:268457 Archived-At: Eli Zaretskii writes: > Please describe such situations, where the escape (i.e. how to avoid > bumping into this subtlety, by either rewriting the code or using > auxiliary variables) is not clear. I don't know. The problem is that when setting buffer-local variables it is unknown which bindings are in effect unless you explicitly look. Recently there was a question, I tried to find it again but failed, where a user wanted to set, or expected a variable to be set - was it `lexical-binding'? - and that failed because there was a binding of `lexical-binding' in the call chain that prevented this. Too bad I don't find it anymore, it was not long ago. Maybe the example has even been fixed now, but maybe it was also the case that Stefan mention, that case where the right semantics were not trivial. Anyway, I mean potentially any operation where a new buffer is created and set up, and any bindings of variables that may be made buffer local are also bound when creating a buffer. Dunno, like, creating a new dired buffer from dired, and you need to bind the same variable to create the buffer that you also want to make buffer local. I don't know whether something like this can happen at all. Stefan's examples use `setq', not `setq-local', so maybe everything is just fine after his fix of this bug. I can't tell for sure because I can't read C very efficiently and we don't have doc describing this, so I am not really a good person to ask. Since Stefan is quiet, let's assume the situation is good enough now. Michael.