From unknown Fri Jun 20 18:00:24 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#78608 <78608@debbugs.gnu.org> To: bug#78608 <78608@debbugs.gnu.org> Subject: Status: 31.0.50; Todo mode bug revealed by setq-default change Reply-To: bug#78608 <78608@debbugs.gnu.org> Date: Sat, 21 Jun 2025 01:00:24 +0000 retitle 78608 31.0.50; Todo mode bug revealed by setq-default change reassign 78608 emacs submitter 78608 Stephen Berman severity 78608 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 11:54:24 2025 Received: (at submit) by debbugs.gnu.org; 27 May 2025 15:54:24 +0000 Received: from localhost ([127.0.0.1]:42768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJwdD-0004gU-GJ for submit@debbugs.gnu.org; Tue, 27 May 2025 11:54:24 -0400 Received: from lists.gnu.org ([2001:470:142::17]:47038) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJwd6-0004fU-6d for submit@debbugs.gnu.org; Tue, 27 May 2025 11:54:20 -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 1uJwcz-00012q-4M for bug-gnu-emacs@gnu.org; Tue, 27 May 2025 11:54:09 -0400 Received: from mout.gmx.net ([212.227.15.15]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uJwcX-0004pM-OG for bug-gnu-emacs@gnu.org; Tue, 27 May 2025 11:54:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1748361206; x=1748966006; i=stephen.berman@gmx.net; bh=4WbG7vp5YUUhKwgohjIaYsresAa/Y8mYwcHZCm/HK8k=; h=X-UI-Sender-Class:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=MF73Bv0mvRE2dSi+Xl2I2FKh4WM4gvPrCSli9zO1uAh+2QGs3uMGYO5kANVKR1fm WyuLuYo3iBD6NkxEvUYahJtm5JOrlPLk1eABjtw/I6xXFKEoQL3DpaOd+HoYWfB62 ur6056p4YpDgeqPebarA9IlW9t8zHTLQsVhBTR1CK/a9+JqFLZ9+dSB+IROMdboUl EMFWm7Y//c3C1tT0KpLYPdkKGaCskI6HmuQ71osckC+vHhtuY3bXM5Kmm8DZrlHO6 MczDGzQo1SnmkyZHyKP72EJysp41P2EWZRV3cu9ZXLBTn2dllT1pf1bytM2eduajT sQXaNP1MdvqGqtS/yA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from strobelfs2 ([94.134.94.124]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McY8d-1utobI3veH-00b6rG for ; Tue, 27 May 2025 17:53:25 +0200 From: Stephen Berman To: bug-gnu-emacs@gnu.org Subject: 31.0.50; Todo mode bug revealed by setq-default change X-Debbugs-Cc: Date: Tue, 27 May 2025 17:53:24 +0200 Message-ID: <87y0uif3t7.fsf@gmx.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Provags-ID: V03:K1:PhiIFjx4eB0c5IH/7rB13+sGCsvhvs7H9pARkVp00nUKyPTuMtb vBtrUReHhjkpyUzQTV5F1m3YK/NQl5vglmBIUFqW3bcVmnCBpvkX6nQyK+6O+LH8eYEeA0H SWmY5kY7DCkryugBaSUZNlGKlcb69ujYGYRvv4sepkchPbQxOXl8g7yb+VXVkbnQvvFEncx JL5PXIjB0uvf26e+Nbi+w== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:6RIGcOwGkq8=;Ae0GW6vJdoQTsPXu16jGV3xpR6y VKiZ6i4X+NoXgdj20UYwX+HUpWG+b3vTStX/bNxr1EDk78MWhld/YYkoPIqeywPV/O90PxZk9 bROBn6UFpfevlUvSGfJEdv19UTdJKxbpmycTpIH3c2485q7auSKtinaPGSRUy1ztTufv8AeYt JKcOC2+lxTcmnaVHerZL8jYCBcj2vo2FxAzU5H9vuYe17UGQLvKz+wSHRIT4/zDZVDIKTg4Z0 eoqhy0tm6v8RKGzfbuZT082tvlI56ptWrUXoRGxjXLfkn/UKCqo7ZSa37+rt4ksqNVo5NycFP xKsL5yzUsMYqvIvd84Y1fSti2ylAEkMkhPNeGTuUsutYwQMFeB7yL+2MOzwgP4g5nxMkFgp1a SFz8sfHag5UcHqCMdh4jXYNTYIf1pHvxCsIe845g2GkbXARZu2QIpmiDv/4i7z7aADvR2+OUD cOsQlJHtrhVAOac+Tsijl34T/eumk9E72ZtTc54dQvlSepdx1SY9IXUer1ABD6JIFNifQZ6oS 9zaE2bkJGDasUlu1fKZaBf4pzxwhskArV3IQnKgRyUP0rj9o7GR2wX3s9U5RkyVRbUgGsVI3R b+huTlalDWurCC0q/SaxBEBywQVmxd7rfb/NqlBtpwBCIgp/X6B6ZqJ9KuREuy5KimeJpZO48 8AQHV3FQNa4bfB3fA6WhBquzoJ+aptbTeiWVTi358FNcIi9ptLJW7wSMs16MlPk1uQ4bSPHYg Sjftm5ELYSjVwDkN3Wuoh0oWFOegmR5GSqWxNlcQUHuIcKft/TMiQX+qU9gB5Q/WZIKdg2bjt L5epbesuKkuaqb7Tzu1o0J7HZJE6WMH+uMNB2Z0zk0m95ueyGOiwzz7kmE07zPkgbugjngW++ D5MPt5lfnxQ2FxPgObq1CxkZ3xCeDYlY5PjL8ZLYe2qx3gChHcI7WbsZ3SXJ2SJTZs/Zfb/3c PePcOHIoXvZLY6bYS7p5cS92iROuyEnHEfCrYV/sLhrdt8nhRhmYeam24XncrNrbQl1yC77Yb DxjXMHlxKPvN+UyyGn5mBaGEHFw4l/fGctLLFli6sAOMbYvhauP6E5y0p1z7TZcShCcMBtIdb SRFpfDXMhmv/GAYUQox9L64XhqTW4PPY/PKNkFidhSNqkrz76BCqBI41aAsmuIOrrv3UZJLvs kjxsFZ7u8+UPtWnG/K6OStZqhg47AcsB+b/EftbWY+rfH1xPaZS/UYZK8R1vhIv8OEkdbJVUc D6hHqwUsGMPkweDDsBaEpmubIWSMYw4XjMeJSfLGWb701PGyAIltD5BYqw3CJwtJsJ5Wmvj/X 76OTrx3hmAgvCwSWk25rM/NxOOoE0ce+XU8x4Ot/KDsbAxDFWRYslv1QE0UECXJY6HksHPx5f r9M7azpLIQH+rvyPM5UwRZKCZ/V99K94wL7FFhy2oPJ3T470pYzkRw0aTFbDmsAo2fwKfx0xY jIv35qHHm90gkNGWKRCLLBbkFFHtId6vXtvu92TxP9DHDRRhb/ciBvsZAVyTkJoeHDxKREzDI wKPqyasYZdveSnXYtQkmARAVzhANZiDbhS00JB+cuCRf9wDC3i0lPFuSp8abvm9YFCf1gfUik IUQRX+tUPnhEb2FS8K2Hm3SvBP2ky7TiUMm5HEPCcOLFctqJF/UAGzScrhbi/56g0xxQV2WcI udruvAwvi/weEbZEtDj0Z1mAhk/I1VaME+SdMg4l+XJj9bS9VFf4BPLeUs3p695hVAERlqqwY mp89n5RtddBU6rz1zp8iBJBEPQe9ra3JtKVWWLarHFV45btWaelodA04hrvjdFUgBGq1tk+BU AXPiXe7LTK6eq6FSHTrGabb1AoJyOL1OK85mkzW7Xr2iiMTf12EvKhl3Ie1OCu0L66VwKPi+8 num+6uFnphYD7W4rP1vkJiDysQwmR7Y8EGC9GgX2OSvEAE5a25uCESu31wlBcNDBGxTnK1pVG GV7jz/0yWb4OFOHSFlrxlkwK0C0OUXQxn8WEG/+1Po7LV/irtPXbxpC+wsZhYn9w/RKjM9CFe G1WkgWp8ohWEbuOjXA9Rdxw/LuVq0eGFqkA40HQqj8McHg2WvENYYWjcUTVNmzoa0A8YIQeMR WTQ+zlcJ7GIb06vtM+cB13ru3Bewkqpy8jU4Prfznn1AF842tLwPBXTAEYCmtciU/hfqhZsxx Ws4bj8UN3NV+FLMJeb5NWIyDw9AGLQpEdngLp7Hj8FFr8yeaEYvmWPTta59De3qB3bv5Rn2e5 7tqOxW36VX2G6NVjGD/1rzrGuqFd0IynLbqDLg+qUeXsEA6Xyl+eqz0+Lm1IFASYDkfyIpTcP j7pxFJo4EhPvtIP6JlhbxqQykTyQ+mGBEN7Dw9xX5gQdQUv2/jvG3dCEE5z+QkPaNdH0gOLtA q5JQ32y2r0zdarswpJkwC2alhNzBGLq/J2LuARNX9/lboxPmsNZrIJA+vWvTrM65G9V6057T0 7LCNeUhuco29dTnCafsn/OMDKM9szVQxRd9mlLpM/GxVl+lw6l4D45/Y1hW2/zbyM87JbVJsl 2r8yzn+5kRFp2pbdRguG+27lnAWCiLyY9lgdK8DRrvNBdv+XaGn8B0T3M9NofzgFGqQIi2MsU MiykHJKKq/i6/XZWuksTeZCBiCh8l0ta4/Of1lZIlTjHyrDYfP3P8UTjUKma+/FDH+5ihQV0W +7q6os8H6hrtsoA42V/NCSRuugq3oRNaOgrHN5udJIaNHLTK7SzhhGcSkrE9J83msURqW+cGW NtYTip5uAiBMxyOLqKS1J4AWnKiSnpcuS3dj2VPPx8RmtPOKwg/gYOMoLay5babw4bnYZ0Ff5 aA4H6m1fjFeyiZGPtL/A9CSQQPymGZukLdiYXfaymAAIxKdd7kjoufLRM6fGglJxstjAy3R7B kEydNnflQgPR5nkvvF4y2zlW2IkhKOQLBYUEoOVd8pZF9RO1CjX7/CSBrzd9IyVP4dnracCKw x3Kd4W9YU0IRyjlFzT/2KMpDztdaz4Ba5LO8/mqtVKMvwKJEZaE8e42CPHWOhCg9NVgtf4z2A MqqKs1a9vlI4wZAXPoCvN46M1Xf9XBoR3Pl4Q8Zf72erAHKARyg+AN3nBvvePyPvAmK1a0M4M FtA4LEEcU4AdOqIK9SVRlJhaQFVHeQQuhkpT6G/IaQ0SPbrTYM/FHnHnwPN+EYuURCeoG/Ff7 wRwNqyyL0vbYldNoXUP+mMIJnK9hXixyROTSH0HuOBQmq8lvAzVs1dUNdAsochNQStBEoU5Iz aFp4LA+rAeGqAEvMzVu12kMQcdX41cMgqe86WvIbAgemisD+1DbjUSZ3F0NB5txgHq1rAj+gl MbDPpuU Received-SPF: pass client-ip=212.227.15.15; envelope-from=stephen.berman@gmx.net; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=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.0 (/) 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.0 (-) --=-=-= Content-Type: text/plain TL;DR: There is a bug in the command `todo-jump-to-category' from todo-mode.el that manifests itself differently in master and in earlier versions of Emacs due to the change to `setq-default' made in commit f3e0bdf1b98. A patch that fixes both manifestations is provided. Background: As documented, `todo-jump-to-category' visits a user-specified category of a given Todo file, and if the specified category does not exist in the Todo file, the user is prompted whether to add the category to the file, and if confirmed, then by default there is a further prompt to add the first Todo item to the category. The command can also be invoked from outside of a todo-mode buffer, but since it is not autoloaded, todo-mode must be loaded before it can be so invoked. Problem (master): Recently, I started observing aberrant behavior when invoking `todo-jump-to-category' before visiting any Todo file in todo-mode (I load todo-mode in my init file): upon jumping to an existing category, I get prompted to add a Todo item, although the category is not new. To reproduce this: 0. HOME=/tmp/${USER} emacs -Q (start Emacs in a clean environment) 1. Type `M-x todo-show' and at the prompt type "test RET test1 RET item1 RET" to initialize the Todo file "test" with the category "test1" containing the item "item1". The current buffer displays that category in todo-mode. 2. (Sanity check) Type `q' to save the newly created Todo file and bury the buffer, so that the current buffer is no longer a todo-mode buffer. Then type `M-x todo-jump-to-category': this switches the buffer back to the todo-mode buffer displaying the category "test1" with the item "item1"; there is no prompt for a Todo item. 3. Kill the Emacs session and restart as in step 0. 4. Type `M-x load-library' and at the prompt enter `todo-mode RET'. 5. Type `M-x todo-jump-to-category' and at the prompt enter "test1" (or type TAB, which automatically inserts "test1" after the prompt, since it's the only category in the Todo file). => The category "test1" is displayed but now the minibuffer displays the prompt "Todo item: ". Solution: The following patch fixes this, so that at step 5 the category is displayed and there is no prompt to add an item. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=todo-jump-to-category.diff Content-Transfer-Encoding: quoted-printable diff --git a/lisp/calendar/todo-mode.el b/lisp/calendar/todo-mode.el index 22be471ef82..ab5e61a0787 100644 =2D-- a/lisp/calendar/todo-mode.el +++ b/lisp/calendar/todo-mode.el @@ -952,12 +952,9 @@ todo-jump-to-category todo-current-todo-file) ".toda") ;; Otherwise, jump to the category in the todo file. todo-current-todo-file))) - (len (length todo-categories)) (cat+file (unless cat (todo-read-category "Jump to category: " (if archive 'archive) file))) - (add-item (and todo-add-item-if-new-category - (> (length todo-categories) len))) (category (or cat (car cat+file)))) (unless cat (setq file0 (cdr cat+file))) (with-current-buffer (find-file-noselect file0 'nowarn) @@ -971,7 +968,10 @@ todo-jump-to-category (todo-category-select) (goto-char (point-min)) (if (bound-and-true-p hl-line-mode) (hl-line-highlight)) - (when add-item (todo-insert-item--basic)))))) + (when (and todo-add-item-if-new-category + ;; A new category is empty on creation. + (seq-every-p #'zerop (cdr (assoc category todo-categor= ies)))) + (todo-insert-item--basic)))))) =20 (defun todo-next-item (&optional count) "Move point down to the beginning of the next item. --=-=-= Content-Type: text/plain Analysis: The current code in `todo-jump-to-category' compares, via the buffer-local variable `todo-categories', the length of the list of Todo categories in the specified Todo file before and after specifying the category to jump to. When `todo-jump-to-category' is invoked outside of todo-mode, `todo-categories' is always nil, so its length is zero, but when the user specifies the category to jump to, `todo-categories' gets (via `todo-read-category' and functions called from it) a non-nil list value, so the post-specification length of `todo-categories' is greater than the pre-specification length, and together with the non-nil default value of `todo-add-item-if-new-category', this results in the prompt for a Todo item. The above patch eliminates the before and after comparison involving `todo-categories' and replaces it by a check of whether there are any items in the category, since an existing category should always have at least one item (perhaps done or archived). Trigger: After I debugged the problem on master and came up with the above patch, I wondered why I had never encountered the problem until recently, because most of the code involved hasn't changed since the current version of Todo mode was added to the Emacs repo twelve years ago. So I executed the above recipe in the emacs-30 branch and was surprised to find that the bug does not happen there: after step 5, the category "test1" is displayed and there is no prompt for a Todo item. Debugging showed that this is because the value of `todo-categories' is nil in emacs-30, both before and after specifying a category to jump to. This difference between emacs-30 and master manifests itself in the function `todo-category-completions' (called from `todo-read-category') around the following code: (with-current-buffer (find-file-noselect f 'nowarn) [...] (todo-mode) [...]) In both master and emacs-30, before entering this sexp, the buffer-local value of `todo-categories' is nil, but after invoking `todo-mode' its value (for the buffer visiting the Todo file `f') becomes non-nil. After leaving the `with-current-buffer' form, `todo-categories' retains its non-nil value in master, but reverts to nil in emacs-30. The mode function `todo-mode' calls `todo-modes-set-3', which contains the form `(setq-local todo-categories (todo-set-categories))'. This led me to commit f3e0bdf1b98, and indeed, when I undo that change in master, the problematic prompt on calling `todo-jump-to-category' does not happen. Problem (pre-master): Then I tested invoking `todo-jump-to-category' from outside of a todo-mode buffer and specifying a non-existing category, and saw the same pattern, which, however, now reverses the problem status: the new (empty) category is displayed and there is the now expected prompt for a Todo item in master but, now wrongly, not in emacs-30; thus, in this case the behavior in emacs-30 (and earlier) contradicts the documentation. To reproduce, carry out the above recipe (in master and in emacs-30), but in step 5 enter "test2" at the prompt instead of "test1". (When I implemented `todo-jump-to-category', I apparently failed to test this case and haven't made use of it since.) Applying the above patch to emacs-30 also fixes this problem, and with the patch the other case (specifying an existing category) still works correctly in emacs-30. The fact that the latter case also works correctly in emacs-30 without the patch is evidently due to the problematic behavior of `setq-local' fixed by f3e0bdf1b98. The patch has a narrow scope, so I think it's safe enough to commit to emacs-30, even though the bug there is not a regression; but if that's not acceptable, I'll commit it to master. In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.49, cairo version 1.18.4) of 2025-05-24 built on strobelfs2 Repository revision: 492adf20b91520e96fb198e6e936e3145359c43b Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101016 System Description: Linux From Scratch r12.3-20 Configured using: 'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt6/lib/pkgconfig' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3 ZLIB --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 28 06:46:30 2025 Received: (at 78608) by debbugs.gnu.org; 28 May 2025 10:46:30 +0000 Received: from localhost ([127.0.0.1]:51200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKEIn-0005EE-ER for submit@debbugs.gnu.org; Wed, 28 May 2025 06:46:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55576) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKEIl-0005Ds-24 for 78608@debbugs.gnu.org; Wed, 28 May 2025 06:46:28 -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 1uKEIf-0006SQ-0u; Wed, 28 May 2025 06:46:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tgDm+5qQSt50oDpTEC4IR98LLbWnWnfPwii6IzpUCO8=; b=RRSCfig/vLbl yfqNCT4yAf7fJcy6vioCv73OVAqJC0FVKPut1dgTD+8C0qVOg2NzoDaRCCWkFopM/+IpVibvnQ2D6 3uUuKR9CCRm6lLHhXPCOit3LTf0dt3w/3udpFiK/YVqs/IJC8gv7a59eLqVBdueFMKE0WeNJhYVgw 84TdB3ChIjob/z2sWQQt3+a00Y875Cy/O0/0qYoQELEpCb+wwwaUhi8KhwiSfFPrwoTjGlMFvbjbj Qr10L1TBOzWiBS6s+0Y9gZTYXC40G0ce5piJLTjtenHiGKgXSqZO654BzkDaoEpuNWibxw0HLsvCc 5hP0BcCdJugXBTj9PjK8dA==; Date: Wed, 28 May 2025 13:45:33 +0300 Message-Id: <86zfexvws2.fsf@gnu.org> From: Eli Zaretskii To: Stephen Berman , Stefan Monnier In-Reply-To: <87y0uif3t7.fsf@gmx.net> (bug-gnu-emacs@gnu.org) Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change References: <87y0uif3t7.fsf@gmx.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78608 Cc: 78608@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 (---) > Date: Tue, 27 May 2025 17:53:24 +0200 > From: Stephen Berman via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Trigger: After I debugged the problem on master and came up with the > above patch, I wondered why I had never encountered the problem until > recently, because most of the code involved hasn't changed since the > current version of Todo mode was added to the Emacs repo twelve years > ago. So I executed the above recipe in the emacs-30 branch and was > surprised to find that the bug does not happen there: after step 5, the > category "test1" is displayed and there is no prompt for a Todo item. > Debugging showed that this is because the value of `todo-categories' is > nil in emacs-30, both before and after specifying a category to jump to. > This difference between emacs-30 and master manifests itself in the > function `todo-category-completions' (called from `todo-read-category') > around the following code: > > (with-current-buffer (find-file-noselect f 'nowarn) > [...] > (todo-mode) > [...]) > > In both master and emacs-30, before entering this sexp, the buffer-local > value of `todo-categories' is nil, but after invoking `todo-mode' its > value (for the buffer visiting the Todo file `f') becomes non-nil. > After leaving the `with-current-buffer' form, `todo-categories' retains > its non-nil value in master, but reverts to nil in emacs-30. The mode > function `todo-mode' calls `todo-modes-set-3', which contains the form > `(setq-local todo-categories (todo-set-categories))'. This led me to > commit f3e0bdf1b98, and indeed, when I undo that change in master, the > problematic prompt on calling `todo-jump-to-category' does not happen. Stefan, I think this means we need to call out this change in NEWS as an incompatible change (unless you think there's a bug in that change which needs to be fixed, and will make this change compatible). > Problem (pre-master): Then I tested invoking `todo-jump-to-category' > from outside of a todo-mode buffer and specifying a non-existing > category, and saw the same pattern, which, however, now reverses the > problem status: the new (empty) category is displayed and there is the > now expected prompt for a Todo item in master but, now wrongly, not in > emacs-30; thus, in this case the behavior in emacs-30 (and earlier) > contradicts the documentation. To reproduce, carry out the above recipe > (in master and in emacs-30), but in step 5 enter "test2" at the prompt > instead of "test1". (When I implemented `todo-jump-to-category', I > apparently failed to test this case and haven't made use of it since.) > > Applying the above patch to emacs-30 also fixes this problem, and with > the patch the other case (specifying an existing category) still works > correctly in emacs-30. The fact that the latter case also works > correctly in emacs-30 without the patch is evidently due to the > problematic behavior of `setq-local' fixed by f3e0bdf1b98. The patch > has a narrow scope, so I think it's safe enough to commit to emacs-30, > even though the bug there is not a regression; but if that's not > acceptable, I'll commit it to master. I'm okay with committing this to emacs-30. From debbugs-submit-bounces@debbugs.gnu.org Wed May 28 11:05:18 2025 Received: (at 78608) by debbugs.gnu.org; 28 May 2025 15:05:18 +0000 Received: from localhost ([127.0.0.1]:54778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKILG-0006Eh-1B for submit@debbugs.gnu.org; Wed, 28 May 2025 11:05:18 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7512) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKILD-0006DI-Ot for 78608@debbugs.gnu.org; Wed, 28 May 2025 11:05:16 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 60A11808FB; Wed, 28 May 2025 11:05:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748444708; bh=md3vKxKuJ6LWRxjC7K70W2kR7l3DBT5FZ2g0cJ9vaZU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MiciW3NEN7FcZFGdeU7PG2Eixa1I3mKxmSVeHf9fLAbAy9rwNc7vEfZSyo1oXgAGi FNju3x7apivB6Qq7mQgwp2N0XKvrDlyS/F8vVccd4ISgqR7S6TSUviM+KBCezyKrC9 zfmCzXnDtmgfACZyBIoaPzyff17zcEfUQPbWM1wALmAXyxZRk1P0AveiFczOMpHcFF aX4i1by3oWMGn+Ry1LJ4eU3Eh6Mh1oRfkQq194Q3u+Bwuff6zuVi3nh/DrzPTcUH9Q J9jvAVVuJO5gC5KHjOfKR845U1yj+JSv6Y8hkkv6m1K4KlL5Q4XuPkKD4cu7Hf91RL OIAtLgpxQI2BQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D13E080898; Wed, 28 May 2025 11:05:08 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BE6621203A5; Wed, 28 May 2025 11:05:08 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change In-Reply-To: <86zfexvws2.fsf@gnu.org> Message-ID: References: <87y0uif3t7.fsf@gmx.net> <86zfexvws2.fsf@gnu.org> Date: Wed, 28 May 2025 11:05:08 -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 -2.710 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 KAM_SHORT 0.001 Use of a URL Shortener for very short URL KAM_SOMETLD_ARE_BAD_TLD 5 .bar, .beauty, .buzz, .cam, .casa, .cfd, .club, .date, .guru, .link, .live, .monster, .online, .press, .pw, .quest, .rest, .sbs, .shop, .stream, .top, .trade, .wiki, .work, .xyz TLD abuse PDS_OTHER_BAD_TLD 0.75 Untrustworthy TLDs X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78608 Cc: Stephen Berman , 78608@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 (---) > Stefan, I think this means we need to call out this change in NEWS as > an incompatible change (unless you think there's a bug in that change > which needs to be fixed, and will make this change compatible). Would the patch below be OK? Or should I add a link to https://xkcd.com/1172/ ? =F0=9F=99=82 Stefan diff --git a/etc/NEWS b/etc/NEWS index 33b042720b5..1bbad5a2e5e 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -2139,6 +2139,14 @@ enabled for files named "go.work". * Incompatible Lisp Changes in Emacs 31.1 =20 +** 'setq-local' computes the value before making the variable local. +The previous code made the variable buffer local before +computing the value to assign to it. +This bug fix is a subtle change to the semantics which should make +no difference to the vast majority of uses but can occasionally affect +code in surprising ways if the computation of the value refers to the +variable. + ** Nested backquotes are not supported any more in Pcase patterns. =20 --- From debbugs-submit-bounces@debbugs.gnu.org Wed May 28 11:21:30 2025 Received: (at 78608-done) by debbugs.gnu.org; 28 May 2025 15:21:30 +0000 Received: from localhost ([127.0.0.1]:54915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKIaw-0007WQ-2R for submit@debbugs.gnu.org; Wed, 28 May 2025 11:21:30 -0400 Received: from mout.gmx.net ([212.227.15.18]:50141) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKIat-0007VZ-55 for 78608-done@debbugs.gnu.org; Wed, 28 May 2025 11:21:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1748445669; x=1749050469; i=stephen.berman@gmx.net; bh=8jyWT6tVbTejmSM83rF3XNECSE7L24ZZnBk+83XSOZ0=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=Ty+TaaNWJezFwMD4cPdzBYM9aVXsb4tNl+xGbOuWuyxRNs/XTsKzVU/5QQbR0YsS 1YiRA+hoI+Kqn6evyGNOPKGZRd1rYAQQ78Sk+nRD575x1Go0dO9NYsvyvUvBzzpCl gjLEyCpq2f1/Youb8qRFOsdlsPyV2nKBItdPYVaR4D2BgdAdUcURQGNtjdBxn6apj bvUx5tEgkpR1lyWPmdAVl3UJ8Utd3ZCC+6Rd4ByR1c4HXpcNTXKlcPCs6S1sasEwe 8+dHxYDDDGYiYgqSQkMnRf9PfIvaLWFJsgmFPNv2X7+SHrrDRJDg8vxnCoU7n8BBC 3qV/8uAoWt6sz2T8bw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from strobelfs2 ([88.130.49.111]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MpUZ4-1uhVqz0HEK-00oXFr; Wed, 28 May 2025 17:21:09 +0200 From: Stephen Berman To: Eli Zaretskii Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change In-Reply-To: <86zfexvws2.fsf@gnu.org> References: <87y0uif3t7.fsf@gmx.net> <86zfexvws2.fsf@gnu.org> Date: Wed, 28 May 2025 17:21:07 +0200 Message-ID: <875xhkdan0.fsf@gmx.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:PV2sbkuNM9jsj2+mzC/BRRRkiqnbc+VB1ggNA+O5KVdB1+5ZuTk RkofKq2YVuxpmC6A2VM9tWt2Pw6SK2Gn6QCSgx7f7m+UERK4z9Pd73MkSpg1N6C4rLWeQEz tEZRZoCNhmQQOwL61RKhqlgkqYUIIn0Bupzi8aYOVvm2ZULwnOgCDOkSlt1DtBG8O/Slwss 1UfVsrvR7rqI8BBQzgZxg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:cKZ6i/Kd7Dw=;3wNCLW1YVPrfl3jwKbKpP+FklR+ Z7TZy01D8sQNs4UrUIQ+hm5I+hwPJ7HqJ0q12GFV8ZL4MhV2/kIaDdx1Sl51WQXXks1vho3K0 5dYLESj/pK2fFrykGhLFfKqNYC5hm6hqPZYVt3GNkPupXjeD8EC/SW10fkAoxcqueICwyEUn4 W4nLlav2zyxn1k1FS8Ans9PDazHbAd96vHICs+BiMJY9uZkJzmIuE6IBkQ4YBSzLC3iq4gEiw 2lBusutJ+ZdChOf1Q+Bn0RIyTAogzF0W/RQM1Qulnoum3StNdRin8VqjLOLp0B+0RnlGlz1Ut 8VlQ1juJ/JsfEj5tIsxfU6NLp4Aq5eORTE4pu8M0TVcFyEY0t0cr/FBjvT/aJe3NiRoShvUUR ftg/nqLQmPbfFT7Ng+rRV9p215SRkzt0jSsowYEjudY/rX9ETDsmCv4irm7SDJtlncPm6kHCP bly9WEddN6qWsh73PHYBtjGWXNx3BXSpf3DrJpR7np2y46VNv1tdzJb0C2uFri8mlGEOGZPTp zA4fuK8Kp0tici8UM4yU3WekZlI5+cp7m2J7Dd1/05/tk8yQI9ERNcxP0np8K4BtMVZN8mthX PSFcHHEgtoGRdSzZUfdFfaBHq1wy1BjuBYLBeTF2XAUSzeo/bUoy57v+6Sc2DFSyjChXiLLuC GZus7DAoi1owphl2/PcYTCqxwed5hZ87Yjhhhc6gycajVPMh8pAULG44Ekm0UQVvh4UP/MkVd eaDct/sWiZPsd7469o6hiOrB4dSeqSQVDI3eVW0zUHAqavnCUTpTleEPbvBzZZOa2kuabs5kk Llhuh9cI4vsAqNPLMI+EiYbBZz9/3UkP3HIaYwCherrnFy02TPTFnsIheAc5t73HbaSBwOsEG /FzZ3J0673JETXIHtNvXI2jYmnXAm5XAhI60JFOPv+2vOAAe/OVVVoeOjhHrL+eJm34uArpxS 538Rqf0gFdvd/B/GX45x2sf97RPV0HjJuL4w8eeMc3jSYPxC4VIeMTG67QWoJmx7N6MNvAyoC n9YFh+C2xm5yEtE1thje90BDB2s2cmzVvFx9XZyFamWwIMg3tgs7QIpXnSdO+m+wxLtgqKGfO WqqYA29FC43uti8ALFtSQ/T3cGx2AOQdit73PerE+kvBwIM5NdrKNXkfKXTwsUNz4yr6M3MMR 5PzH88B5i6ZSYfiQeFrzp/ki5Wiqh2gAOAxjQ7Yk5cv+sNP+F15XYRrSy6+AFTzLgwOfnQQ/M AnkVqKCsh2Q7S03/8eI9Nxp0Y9kZYIoTEvPwrm7T0H4WMUlpfKPKDO861HuluBt9NW1e6ERW9 ccWcmeSQ0zoQ8tXO5G7BP/506ANAS+/F6smKtDhCtEJ5DRcUT1s00UDsAC17O333sjojtRY+5 hAEJ9rDpTPc5+L0NZrjG6yn6Vmnt/snB4gYAGJ9FiBfQ2vLV9b9XhEQYds+FLJA1JiGhgvgWy frbW+jnBU0ppTMyiiK7oPxnmTDVn2i1+YRMb3nyj+U3bCyI/DNyGf/F0LtqwkrqOYmHnNjBGB /vl4Usss+tEhyP2b67shdo0l+0pRD83hu6Zm723+AKFqS2qVj0+G/Uc0Y0bEA2P7UBnd/MVzC LArCbqk184jNeW1ygsEhwIcP3IlXjPEDan97nZFRtggeiAg8cdZ2mJz7szNuk8JYIUbzJYNRl Sk/FHOPI+OQS90NAk/6PgjzttpkCENIZIhg9HVd/TI2h7TKuXGieLsxrn981wugTGIJJZA7Oo mZvg3J3rid1gjRwu6zlRDBa04c3L5Mu9HtPwKCu5tv5QmeY0YqzIb3XGDB0TyK/o/90Nb2hd9 zOGZ4FVAdjgAB9grHhxuS5yhnZKi0HNu6c0+LV+ujVjD6Yjj/moYjVy1EwmO4ht4Gmeqw71Ty zRMM13n9P6Qs4tC1N2VM0IWRrPbanREJac7g6PFG6inD9/QktpAV2ksVoSw/gUociSRMiQjTM p+mgLqBl5VgjvzG/iTIzzsiB8/e9Z6KndgVpOoetD04v6MvCpEkOK6s4TxL0dvMsfoZxOM8uJ rMSnR8fS0eQNG6nzPiUcO+Pozdxrk4xw7o8TJDDXVCVDVTyPRyJUYzMyWoUxl/fORy+aTifBv V38VNLdyqTOF7LOSZN0lW6b7VlG/geVl2clX1idnUtPPN6PUDjBEYFb/fwCx4x1eLttrKKseL dtNllGp7uyMqqOgE6kJpeOLMtDE/1R6yDMgPSA7QnGzG4JyL+FEH9RzXJx0y3LhyDrfLy7Nux UXc1QbR2LX+ppL70YKY0qte6MFRKQ0bvbtzfg+K1g9syHvyhqZW4u/YMwipKVAHYrKsE4LZIC LAoQxF6Q6jCPcK5ofZJu6MnRjHg66a7sWc3Znmf4zAuT9o8VKx+sanYl2ZCbyRXRO65F4PpfP P33FElUUCLCH1p5pKVtUAzIjGIRxmbVVz7q/6Cn3EIuQ7kUJiR8lcq3twptWYPuasFDeGLwax 7tKKNGkXtRrzvvQXuQv3PKw/eZiNB1lGwErh46s6yU+rk1+BilJ0B6xK5c2JvEQMV+CzD6Xu8 vn8cMnWlv3JcLJz6YxRc8lQ7O0TGQftEJXfEDMrpsw3ITZ/BqB+ujy+Ht7OcPDvm0uZOdhZOT /aEpHhVR07fmnQhLe6vVqAaKcTAa3t+Uop0Tiu2VVp+1CSKna5s/2WxIS4Y9zQWKIbGCwziGk +B2bY5Dij4g6Vlh2VTBxG0Li7R2fuUBCMNdhoo7JKSiSSrf9GqRNjsIu8ZtlHiCkdoqBj68rc edcnSjueeH6ryNbaLWAAW6wZZPnCz8/sqXeShX/UtJAVeIaHvNKBxyJdeeI7Iap319oEoTdAb q8EK3HK6CxJTKfTadBzIOnPwJIIIjRltmUC/+cJmjt7C3G0LSoCIBch/meuOqL21BTmaVAmEv Vkif8iVp7FtAOqtCxmkOEf7l7AJ5GQdbVCfb+0mo3/CtdXPi01zqEJVEiZzjIGvkrRcO72kBY UcSJodR8hqvefgFX/QLBJGvoCANOKts2m2C/SEJjxkeyV3q2waLVWRGEFuMTrPT+033PpNtZA H0/9FcOdk0lAjNRsxPCzj9g8WMNhf66L0MrSwm2yjOVYAHGxTd5dSOphfSMts/8uKl4656y3G nvI4PUbes+oattVIk2AKwhTiHMLNbIE+KummEkCA0zv/+swaDAtE4ln43oyajxPw1YuneBSJl 3ywckDw/hRcVLaHbZiJ0EasrtXAbEXKpv79Po2DzTNyXsEPHp03X6NNEtiosw48pxUb6gjWJS 9AjF90z0MrkQByQ6TKNYwq2UGs+HqrHkHZ463A== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78608-done Cc: Stefan Monnier , 78608-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.7 (-) On Wed, 28 May 2025 13:45:33 +0300 Eli Zaretskii wrote: >> Date: Tue, 27 May 2025 17:53:24 +0200 >> From: Stephen Berman via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" [...] >> Problem (pre-master): Then I tested invoking `todo-jump-to-category' >> from outside of a todo-mode buffer and specifying a non-existing >> category, and saw the same pattern, which, however, now reverses the >> problem status: the new (empty) category is displayed and there is the >> now expected prompt for a Todo item in master but, now wrongly, not in >> emacs-30; thus, in this case the behavior in emacs-30 (and earlier) >> contradicts the documentation. To reproduce, carry out the above recip= e >> (in master and in emacs-30), but in step 5 enter "test2" at the prompt >> instead of "test1". (When I implemented `todo-jump-to-category', I >> apparently failed to test this case and haven't made use of it since.) >>=20 >> Applying the above patch to emacs-30 also fixes this problem, and with >> the patch the other case (specifying an existing category) still works >> correctly in emacs-30. The fact that the latter case also works >> correctly in emacs-30 without the patch is evidently due to the >> problematic behavior of `setq-local' fixed by f3e0bdf1b98. The patch >> has a narrow scope, so I think it's safe enough to commit to emacs-30, >> even though the bug there is not a regression; but if that's not >> acceptable, I'll commit it to master. > > I'm okay with committing this to emacs-30. Thanks, done in commit 4507b6a9c75 and closing the bug. From debbugs-submit-bounces@debbugs.gnu.org Wed May 28 11:54:08 2025 Received: (at 78608) by debbugs.gnu.org; 28 May 2025 15:54:08 +0000 Received: from localhost ([127.0.0.1]:55196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKJ6V-0001X0-BV for submit@debbugs.gnu.org; Wed, 28 May 2025 11:54:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52416) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKJ6M-0001WA-Ip for 78608@debbugs.gnu.org; Wed, 28 May 2025 11:54:04 -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 1uKJ6G-0000ZK-MW; Wed, 28 May 2025 11:53:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=JewuDZpO07T9VstdQWB/gDvuDjOEmwnA/03DkjXoHig=; b=OoPg32SierKz B8SLjECg8VLAfRnrLqJoqpvt6JHESGW+bgucFuQG5N7oNwEuqjSP8qTfC/ueKBlboxmo4972D6ah9 vKVY+usEIjseRY18kDgVlRYL3zg3H9ur9+oAKbLrXXxUAw2kTxcEUSdFwFRd9n9fKo4DzszQ8dXIs Cf8QjXYeZ5oPR2BxENjFYqdh4yBmzWxSqo1ONdSV9ry3EYxT7PuahpaqfK7dKx1fPgz57Y2UOhWqQ m/buGmMFf9Usv/JymohO0uU5wIldAmy87A6e4K9FN5ZHKJGWBdsr3WHaSPvvbataK1lIf9GlhcGhg k9mDBUyfVGLP/shAr5VL2g==; Date: Wed, 28 May 2025 18:53:50 +0300 Message-Id: <86bjrcwx2p.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Wed, 28 May 2025 11:05:08 -0400) Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change References: <87y0uif3t7.fsf@gmx.net> <86zfexvws2.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78608 Cc: stephen.berman@gmx.net, 78608@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 (---) > From: Stefan Monnier > Cc: Stephen Berman , 78608@debbugs.gnu.org > Date: Wed, 28 May 2025 11:05:08 -0400 > > * Incompatible Lisp Changes in Emacs 31.1 > > +** 'setq-local' computes the value before making the variable local. > +The previous code made the variable buffer local before > +computing the value to assign to it. > +This bug fix is a subtle change to the semantics which should make > +no difference to the vast majority of uses but can occasionally affect > +code in surprising ways if the computation of the value refers to the > +variable. I think this should describe the case upon which Stephen stumbled: code which uses setq-local inside a let-binding (perhaps an implicit one, such as the one the various with-SOMETHING macros do), and expects the buffer-local value to stay after the let-binding is exited. I'd remove the last sentence entirely, because it is not useful. From debbugs-submit-bounces@debbugs.gnu.org Wed May 28 13:00:07 2025 Received: (at 78608) by debbugs.gnu.org; 28 May 2025 17:00:07 +0000 Received: from localhost ([127.0.0.1]:55728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKK8M-0006nu-OW for submit@debbugs.gnu.org; Wed, 28 May 2025 13:00:07 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50405) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKK8F-0006lm-ML for 78608@debbugs.gnu.org; Wed, 28 May 2025 13:00:04 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CD2D6808FB; Wed, 28 May 2025 12:59:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748451592; bh=mYMKNd04pIo4x4hYlk+MmsxBubo92LC7RfJOZJrt4nw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jXlCqQzbbE6zMJ5z3fOVID0UivNVZn0RTGB2Mhn9UNLvyi4ESqoLzu/6Sca3ME6mr +1Ni0DsCyQq3gOmUMjNxuwoUIjNZiQzt1pQe0CTm/TQeFxhTBCNy9RZ2gZtnvHEGU+ OOFpWuEt1L6Q6mVo0M37SS3zbloWJY9P9cVYJsHLZ40kvmrHEtbxhMgpi1CaC5SJoG BTSzsK8k0bVztLUg3zEeJhbsAbdpN0dhr9fiA024DCIAZ9EuneJBFaErbmF6ZxeOPg EPAcCLIdiSUhDqRX7UayHajtzAl+Sc5mC5zozp0tcuy++MdO/sUVuEKLYWVM+3pGMt YF8T7Sfeoq5eQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AD8118089D; Wed, 28 May 2025 12:59:52 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9BF761204CB; Wed, 28 May 2025 12:59:52 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change In-Reply-To: <86bjrcwx2p.fsf@gnu.org> Message-ID: References: <87y0uif3t7.fsf@gmx.net> <86zfexvws2.fsf@gnu.org> <86bjrcwx2p.fsf@gnu.org> Date: Wed, 28 May 2025 12:59:52 -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.171 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: 78608 Cc: stephen.berman@gmx.net, 78608@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 (---) >> * Incompatible Lisp Changes in Emacs 31.1 >> >> +** 'setq-local' computes the value before making the variable local. >> +The previous code made the variable buffer local before >> +computing the value to assign to it. >> +This bug fix is a subtle change to the semantics which should make >> +no difference to the vast majority of uses but can occasionally affect >> +code in surprising ways if the computation of the value refers to the >> +variable. > > I think this should describe the case upon which Stephen stumbled: > code which uses setq-local inside a let-binding (perhaps an implicit > one, such as the one the various with-SOMETHING macros do), and > expects the buffer-local value to stay after the let-binding is > exited. Maybe you should write it, then because you seem to understand that case better than I (I did look at the code to try and figure out what was the specific origin of the problem but .. failed). But note that it's only one case that can be affected, there are others. > I'd remove the last sentence entirely, because it is not useful. I wrote it as a more generic description: the todo code is but one case where the behavior difference can show up. Maybe it's too generic, but I don't know how to be more specific without being *too* specific (i.e. fail to include cases which are affected). Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed May 28 14:28:34 2025 Received: (at 78608) by debbugs.gnu.org; 28 May 2025 18:28:34 +0000 Received: from localhost ([127.0.0.1]:56420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKLVx-0000Is-SD for submit@debbugs.gnu.org; Wed, 28 May 2025 14:28:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40650) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKLVu-0000IU-PO for 78608@debbugs.gnu.org; Wed, 28 May 2025 14:28:31 -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 1uKLVo-0006Qj-VA; Wed, 28 May 2025 14:28:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=i7i87F6ciwgwwOuG6hvqjNE2FVfO/G4oxvle64IXI0E=; b=FpNLAw82Mh5q J6Akj2YNZ6pvAEOue3XprFOOmZp/VZU1AeENcyRJXgz5qG+xT0fRpKRP1YKvaQoMso/FSZ9v4wpqx +SXT1k+q30IJKMjGc3JQOpQE02vamxZD4XKngWPK1YqWUPJKKNGdaFu/NM7D/QOjNNGYIDTuDOgcF pJuZ4D4G6ku0FGetaeh877sJr+rlKvSvYTRekDsFWufPNtSYpqem8yRT1yG0eD4tT7gX7cIcIesnl 3SKAnKbrgqq4bksR1TLkdkMPPyfru7JYE6Q+O9waX1Mo8T56/2+gq9yxHkcLShB8MLUZR2cBUE7l7 Mw14CnZUlYMLwYfyiScC2Q==; Date: Wed, 28 May 2025 21:28:22 +0300 Message-Id: <865xhkwpx5.fsf@gnu.org> From: Eli Zaretskii To: stephen.berman@gmx.net, Stefan Monnier In-Reply-To: (message from Stefan Monnier on Wed, 28 May 2025 12:59:52 -0400) Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change References: <87y0uif3t7.fsf@gmx.net> <86zfexvws2.fsf@gnu.org> <86bjrcwx2p.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78608 Cc: 78608@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 (---) > From: Stefan Monnier > Cc: stephen.berman@gmx.net, 78608@debbugs.gnu.org > Date: Wed, 28 May 2025 12:59:52 -0400 > > >> * Incompatible Lisp Changes in Emacs 31.1 > >> > >> +** 'setq-local' computes the value before making the variable local. > >> +The previous code made the variable buffer local before > >> +computing the value to assign to it. > >> +This bug fix is a subtle change to the semantics which should make > >> +no difference to the vast majority of uses but can occasionally affect > >> +code in surprising ways if the computation of the value refers to the > >> +variable. > > > > I think this should describe the case upon which Stephen stumbled: > > code which uses setq-local inside a let-binding (perhaps an implicit > > one, such as the one the various with-SOMETHING macros do), and > > expects the buffer-local value to stay after the let-binding is > > exited. > > Maybe you should write it, then because you seem to understand that case > better than I (I did look at the code to try and figure out what was the > specific origin of the problem but .. failed). But note that it's only > one case that can be affected, there are others. Stephen, would you mind explaining in more detail what in that commit caused the regression on the master branch? I'd like us all to be on the same page before we decide how (and whether) to document it. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed May 28 18:58:53 2025 Received: (at 78608) by debbugs.gnu.org; 28 May 2025 22:58:54 +0000 Received: from localhost ([127.0.0.1]:58197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKPjY-0008QI-PP for submit@debbugs.gnu.org; Wed, 28 May 2025 18:58:53 -0400 Received: from mout.gmx.net ([212.227.15.18]:38323) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKPjT-0008OI-OX for 78608@debbugs.gnu.org; Wed, 28 May 2025 18:58:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1748473104; x=1749077904; i=stephen.berman@gmx.net; bh=r5NPovlSazyh57UQgomIOaodhYQYBlbhAf0q4X25mIw=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=DivgIwr4mROfjoTf5YRx31d0fJ+WTKW49aWwP7lRV8DRnU+dCjv03hKUimBCFyi7 LWOei7D9mX0nHafRzXewoHMnlmGRiL88OerKXRDPV56ztNvm5hKBMfTbA2wWqj7WP PEm0VZXVGtfVCOiRLuxPCDmo6Jn1D8Qq9+hSleRfrNbnjpFlNzYrkLaFHL9OYdff9 9RWgCFM92zm/KyQWIlq6trlGpSC8mLBIJ5w5kmSjoFPu+F4mpzk1xseYB56AU3iEq yEC+2eTZWO7wkp268f5qOgKrvz3QBgSqukEoiCHuISbIhMXZnDUxQGveKkl8IVXJ/ Bq0g8j8oZQZOYjLpsw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from strobelfs2 ([88.130.49.111]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MLR1V-1ubG3Q3I0J-00Hzm3; Thu, 29 May 2025 00:58:23 +0200 From: Stephen Berman To: Eli Zaretskii Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change In-Reply-To: <865xhkwpx5.fsf@gnu.org> References: <87y0uif3t7.fsf@gmx.net> <86zfexvws2.fsf@gnu.org> <86bjrcwx2p.fsf@gnu.org> <865xhkwpx5.fsf@gnu.org> Date: Thu, 29 May 2025 00:58:22 +0200 Message-ID: <87tt54bawh.fsf@gmx.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:lIThaX5fCxs5yfKyKo66YmZ3TZ7vmNvJieqbsbNgNxNx6T+/agJ duSijnrI/A6R0Sodc1/ZbtIm5DF5+c4OZToBCb94baWlDidfzMPY+pCU9PttmgflSPsMKC/ vhbZ4a6Q2aBivYYLJxZROoC7hOAHxsOe7Y4M+d7FR2hKVr4b4GwfoLv4YFJNMAKx8+c6/sQ aowtpxCaHbMgH1CNG5vRw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:6FPFv6hfK/0=;o/6o8uhslu4RM8UNkEngXVt2X2E 7Vmqu6w7Od5DPSgZebvxLiA/XlTJilt7yGOj5isbru7Kwcuq/PcxpITcl98Q2tP1/nSLXOtgV z0Dx/MX4uBniqFLTX8FrbFEwwcJHMQbEYWeJzJhL4/W0WInDOI1H1MWrQRX4+ZScjXt/k190V TsFqmXYgloYXoKjUyaKNc6wWWC9XKXNOd6drpHqnLrw0fky5p7P4/ZpHDN/rPPvYWRFUOFI5G 3QISCUga6HlxSZkvrEprCIiLfbKjEaiId83ZqWz1hs7YGiRK8AkbDMZrj22MpYd92VCdazZ+v hfUrMb+0EBCMmtV3Px5OkN4FFHwunYQ8yMcb6A1/JWVmg4FHYwOgpHrvIv5LsBatZTWzxrAvt MD7Zpt+kgysdNsL9/XHzFoyo4Ve/yNAfHNH5gTBCx1nl2I3F9DfKMeQDyBzNKwIc8AQmrUnv+ 49oOZ54Sb2rbldaFQAyA4E+LPi5PcvogIPcA650ul3rmMXwYZbEYVRFwOT3RGCeSBleNctN0x yknuqCfLQPDRSmwgdif4W3Ek22jkFdnaStxQwoQxQ9FrAQaLrqP5KifwOEBY+Cv82UbVUy1Kq OEhLYuDcG7mlEDNhC2MWeYZkOsekO2Hw9DoYjXh16yvas1STtXZTgTDzkGVP5y/JrH6WJoGon oIwYRaViqxm5edxXG/p8TRvq3llePnEBkEtI6Pwtvksb6k+N33zFXRbITjFPJQPlJBcS/2cTo BFoxXVQp/j/MrmluILd9If82D3W37QrHU/fYUSk6gPV4K9jeEZNvljjmql1ZmYr/jUuukdVuX e9c1fXzUcHdQqFxLxVvUPAYT/XkGuO+2b9bUz9sjwQAk6b8VebKJuJgmQmu4Atk07Dy3WwuKx 7OCUG91FQDeYC3rY+eK7TSwU3Ehi5+EgfESFJ6W9PjjFWrd6Of1nuImC9ezaSna5kWJmiABhc lINW8+kqI9Lf88cU07/1XkxcdHqCnj6Tu3Q0tYKJxZxjEteU7icuwN7BKExYORRBQBSbrjShb 2egHMQqpCpRd6UCF1zTHihlfTcbAXWs/A0VD7fHR6oCq4Eh9bI7ShsULlDCBaRW3zFdrHfn1P WkCYWkK3Dcfd7IQCsTxIKkuMsvp2YKochaIEF+aOWByBORFQiB5+6YBv7tSYcwIYrMtdNzc0a j0BEwLlb1pAWRMgPF1/FXbJ4LNK8nbpeNVJJaSquS+jvOfh0Cd+h1uVFSVY3+OCBYcvIOQkXd Iyxs7xIutwfQGhor19NvJ+HfAKdNi7zjiO9B1eA0dpa3tbDGwsM5BhhT5SkCt8xzP03cCrBDS yQ1QeNOgpWLJaZDrn0EjutitHz27/XHOjpwEFoonz2nOnRR31BphuBlSqDEF9OcaRaFT2zqJ1 kRd3WmRI5PDUXxYmV08hr5BMBntGBuQJowKiQWwX135HLjygxkoiMr9Nw7/LPBSHSPcZjmKQm AwF5YsCu1tC4kl//TSVPhM3E1Iw9iJcLe8i2OKwefkw9GfbUEcrFXEgvWncHcZOju/dDhYrot zPRO6jU/V+z1tz8oOap9AMamXVjIbMMP87K3OdNp0Yw11SMAUIGYJ7EwcC4EEsnw0Y5e1TgoH fGHahR53uWs4q6HDnqMdw9Xe9RQXSvUcGsUES7mzMVvSbJOs8Zp3UHA3p9JbkalC5FNufBMjz q5uB0XlZ2brRFbC68I84DaOkayBwrMJvWxAb4lvZn85pJzhteKI8j4mcK4y9bVFfZGC4g2qQ2 foDMjxDO9J8f5m92Tb1w2tIq5S0OLwTen2z/Ml9ciqI3iR9k3sJgC+g7rtTwIPUnSBVHhch/D KuO9wsp0tKObcE6cLpVK0A7fzlnJ8Q7fOthlJRSJkN0JlVIA8r2qGDuiApGSfZbv3vbtMsFbL rg7uQ2uGQYkJWag7MJx835cPIGphT/KgXNYQt6kpDKYgcXpIV/3mToL3MkiKwWljRmQYQs2gL qc3/NOKWR7dWW+Ok4tdHyXruZBAgJYFfwZDXQtA643P2yxr9xMYDrWATaMA1kvcxResL0mNFv 3SMGgdP0YigqrAKMKafu7a0CzDx1YPF/yWDZE+U76VNWch1X3lVuIIVpuU3q2AdItRVLXSbLN oKJGuYxxbjO4SsnGNtvLLB7BS3p0VnTKFG18ncRwvyOlAIVo+mEv98kmaoSF7LwbzCkA4ZyuJ cng4yG90Jy2Ect+2citV1CHwPV+J93UL5tGiI+ReKLg1Fxiiic9JS4z6uKJWe7JohyBq/YziS TAXDY3Wwxze9gVhuT773yWeRCDwo5kjWUiD+nqnMKwZLsNXW8ngYAcDC6DkewGHJcWWUBYvQl niuBvG04fSiXgntuyUv9nz3n+h36RVai9sd9ld6/k7HuDBMTYLwxiDisGY+8L9PTm5PJ9sgWO M4VJAoR8aj/SEzEYeNbNYEptCOKEY9974opbrd/fIf8kdjRSzMFzagLP3Ahqmh8crKepBG1QX waQNCwclq0GFsT+Cf3ymCsL3ZClfsPGwd59xI2+fZVzuJ8OYW8oOpgA1KKOL6Ks4kmEheGQpx HnBw4+m137Wm+7lF/Kpi1NRqt2sLPF+Sp2rB8t+1qosjRG5wa9faWQgUN1YBExq+Xikj/L8VU viJwXZ2mIXaAPUqb+DrShinFigTqQET6J6rs0irkRYsHb6M7kFp0sv7q6XbeN3U12Nw1G8bch bcFkVMEhwnc3FKAtg+vz72uO+yHIF+RRvoctSPnW56ccbr5lhxGQS04JFutiQ+2T1BNvYxCQd 2BqJKPvDbN6RmfF7qH1MOWAFbTJ4suEYIbR6qLWq190bsMRJGOeMarTZQ3TxsmnKP19ndbxT3 sPA1yhhMGuVRwtn4K0jifSEcOg062fWpjTVxQkrdJSAcaHyflxSco1iPqY30CLphQPX3B+xYO Xgy42tHmmZ/CDX8VTQKs45TULosOA3sJkqKPegAK932ELatO38hU1weBuifT3gpWkoeQt9KVA 9HF8UKqEQ/4hkgIWjfY4fJswXLcYALn1s0gRDGTbcA1p5wNmbR9KxUeWwh8aSVtgAGFZ4Vxk7 q1BSWp6jCqdcdl54bY0NdAKxFAAkR/Li2ejHiZKhIRk3CKy/yDmkEirIu24Uoa84+iTzXtNe4 cptWoPSIYFJmNXQhZNOW10SAx2v2l+L/4AdmuHlJv6ZVc3yJyplqsXQmitZqSzryNBagAHSuc Q7zNIarYoCc19F3drdFwbscgBMOruP5p0ntoXtYn+ovzTlYd49YtU+GqzVh/6tXhQCE50SOPu fn4XDCJQ8jS8BJ3s Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78608 Cc: Stefan Monnier , 78608@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.7 (-) On Wed, 28 May 2025 21:28:22 +0300 Eli Zaretskii wrote: >> From: Stefan Monnier >> Cc: stephen.berman@gmx.net, 78608@debbugs.gnu.org >> Date: Wed, 28 May 2025 12:59:52 -0400 >>=20 >> >> * Incompatible Lisp Changes in Emacs 31.1 >> >> =20 >> >> +** 'setq-local' computes the value before making the variable local= . >> >> +The previous code made the variable buffer local before >> >> +computing the value to assign to it. >> >> +This bug fix is a subtle change to the semantics which should make >> >> +no difference to the vast majority of uses but can occasionally aff= ect >> >> +code in surprising ways if the computation of the value refers to t= he >> >> +variable. >> > >> > I think this should describe the case upon which Stephen stumbled: >> > code which uses setq-local inside a let-binding (perhaps an implicit >> > one, such as the one the various with-SOMETHING macros do), and >> > expects the buffer-local value to stay after the let-binding is >> > exited. >>=20 >> Maybe you should write it, then because you seem to understand that cas= e >> better than I (I did look at the code to try and figure out what was th= e >> specific origin of the problem but .. failed). But note that it's only >> one case that can be affected, there are others. > > Stephen, would you mind explaining in more detail what in that commit > caused the regression on the master branch? I'd like us all to be on > the same page before we decide how (and whether) to document it. Unfortunately, I have been unable to step through `setq-local' with Edebug when the variable `todo-categories' gets set; typing `i' just returns me to todo-read-category after the variable gets set. So I only see what I reported in the bug report, which I repeat here for convenience: "Th[e] difference between emacs-30 and master manifests itself in the function `todo-category-completions' (called from `todo-read-category') around the following code: (with-current-buffer (find-file-noselect f 'nowarn) [...] (todo-mode) [...]) In both master and emacs-30, before entering this sexp, the buffer-local value of `todo-categories' is nil, but after invoking `todo-mode' its value (for the buffer visiting the Todo file `f') becomes non-nil. After leaving the `with-current-buffer' form, `todo-categories' retains its non-nil value in master, but reverts to nil in emacs-30. The mode function `todo-mode' calls `todo-modes-set-3', which contains the form `(setq-local todo-categories (todo-set-categories))'. This led me to commit f3e0bdf1b98, and indeed, when I undo that change in master, the problematic prompt on calling `todo-jump-to-category' does not happen." Can either of you tell me how to debug `setq-local' or what to look for in the `with-current-buffer' form to try and find the cause of the difference between master and emacs-30? Steve Berman From debbugs-submit-bounces@debbugs.gnu.org Thu May 29 02:14:41 2025 Received: (at 78608) by debbugs.gnu.org; 29 May 2025 06:14:41 +0000 Received: from localhost ([127.0.0.1]:32793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKWXJ-0004hx-0z for submit@debbugs.gnu.org; Thu, 29 May 2025 02:14:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37272) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKWXG-0004hZ-94 for 78608@debbugs.gnu.org; Thu, 29 May 2025 02:14:38 -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 1uKWXA-0005vU-IF; Thu, 29 May 2025 02:14:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=QcZKc0fUeD+Xlbpj1XrMWPjIdL8UFN/0D4bzxqGK/tA=; b=YvVndwZ+8BVw JmBaDccKBZRsQgsrtmkLBiWZSEss/6LGezlA4JPqEyah4k7Kr8hxw/PUTIOmReLQSS+mZrdy1nvTQ HfYF8qsPEhiI9yukGeu6+HvXj2wQExSvFCBUl28m3e4K+Wzaa+AoLWRuJe8iAserMq2c2lNJKfEju bWL4vFuOxn+xq0qbZwOG+0pJM6RZ11z6t//kzy4oKmOjIVI3bUr3tnZjX7UQMUw+wuWNTIsJzMqS7 bvlIOaSSA/iEXLLyNkki9Jt1hd9S1q2kQcFB9byvLXzwVKSOxsbnkB1nvLD3Hqb8iReurfEKAehnn h7wHLOPsfP8u8sX+ObEIoQ==; Date: Thu, 29 May 2025 09:14:26 +0300 Message-Id: <86y0uguenx.fsf@gnu.org> From: Eli Zaretskii To: Stephen Berman In-Reply-To: <87tt54bawh.fsf@gmx.net> (message from Stephen Berman on Thu, 29 May 2025 00:58:22 +0200) Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change References: <87y0uif3t7.fsf@gmx.net> <86zfexvws2.fsf@gnu.org> <86bjrcwx2p.fsf@gnu.org> <865xhkwpx5.fsf@gnu.org> <87tt54bawh.fsf@gmx.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78608 Cc: monnier@iro.umontreal.ca, 78608@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 (---) > From: Stephen Berman > Cc: Stefan Monnier , 78608@debbugs.gnu.org > Date: Thu, 29 May 2025 00:58:22 +0200 > > On Wed, 28 May 2025 21:28:22 +0300 Eli Zaretskii wrote: > > > Stephen, would you mind explaining in more detail what in that commit > > caused the regression on the master branch? I'd like us all to be on > > the same page before we decide how (and whether) to document it. > > Unfortunately, I have been unable to step through `setq-local' with > Edebug when the variable `todo-categories' gets set; typing `i' just > returns me to todo-read-category after the variable gets set. So I only > see what I reported in the bug report, which I repeat here for > convenience: > > "Th[e] difference between emacs-30 and master manifests itself in the > function `todo-category-completions' (called from `todo-read-category') > around the following code: > > (with-current-buffer (find-file-noselect f 'nowarn) > [...] > (todo-mode) > [...]) > > In both master and emacs-30, before entering this sexp, the buffer-local > value of `todo-categories' is nil, but after invoking `todo-mode' its > value (for the buffer visiting the Todo file `f') becomes non-nil. > After leaving the `with-current-buffer' form, `todo-categories' retains > its non-nil value in master, but reverts to nil in emacs-30. The mode > function `todo-mode' calls `todo-modes-set-3', which contains the form > `(setq-local todo-categories (todo-set-categories))'. This led me to > commit f3e0bdf1b98, and indeed, when I undo that change in master, the > problematic prompt on calling `todo-jump-to-category' does not happen." Yes, that was my understanding, and the reason why I thought this change might affect other Lisp programs. Stefan, does the above explain/describe the change in behavior of setq-local in let-bound code, and is it the change you expect from the changes you installed? > Can either of you tell me how to debug `setq-local' or what to look for > in the `with-current-buffer' form to try and find the cause of the > difference between master and emacs-30? I hope Stefan will be able to help you there. But the first thing I'd try when Edebug doesn't help is printf-debugging, i.e. using 'message' to display values during execution. Did you try that? From debbugs-submit-bounces@debbugs.gnu.org Thu May 29 18:48:26 2025 Received: (at 78608) by debbugs.gnu.org; 29 May 2025 22:48:26 +0000 Received: from localhost ([127.0.0.1]:40483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uKm2z-000610-Hy for submit@debbugs.gnu.org; Thu, 29 May 2025 18:48:26 -0400 Received: from mout.gmx.net ([212.227.17.22]:58103) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uKm2v-00060I-PB for 78608@debbugs.gnu.org; Thu, 29 May 2025 18:48:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1748558895; x=1749163695; i=stephen.berman@gmx.net; bh=bKWM8d1W2k9pn09QJr+hK7aZjfYDfCFWV3vcME17Wmo=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=RYD8gtyiQmsFszK/2ctPQk22E9Sy7pveSL/VJQby4U8T1y5YNRVZ6HkUfgpxw+Ib LypKZjhDG4rFmNBAZ8VAiCw6B0gG1yL4daSQkd+3uT0KMiBysangnidZl4qyhJw5V GwvlJPH4LVA5Sy29S3Bvf5U7hEoNRI8/8xGNexr2EaPGzRNJHAZYh7FAHFEjsBv1A BercLEfg98H6Jr0DBeDFYIKWpwtlYT/o65TdA8OzjJd/6ymo9BqMb2MvC7/OdkBow f5g2aW6hBSBjTROJglzuB0qW8QSabDwS+BXJh/ReJw5LQVIJoZaNnGpl4IbN/JahL mHZ1YF2ndN059UutvQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from strobelfs2 ([94.134.95.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3UV8-1uLKH70XZ4-007SkX; Fri, 30 May 2025 00:48:15 +0200 From: Stephen Berman To: Eli Zaretskii Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change In-Reply-To: <86y0uguenx.fsf@gnu.org> References: <87y0uif3t7.fsf@gmx.net> <86zfexvws2.fsf@gnu.org> <86bjrcwx2p.fsf@gnu.org> <865xhkwpx5.fsf@gnu.org> <87tt54bawh.fsf@gmx.net> <86y0uguenx.fsf@gnu.org> Date: Fri, 30 May 2025 00:48:13 +0200 Message-ID: <87ikljt4nm.fsf@gmx.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Provags-ID: V03:K1:L2yvMWejkd16+HP1xhoxO17yWZj062HimksWAlWdegmYdGDiTXC 9HsVlFxfO3vjarHvXedlxubJed/2HG367a48h1uo/A69NRUoZ+SIZFIofL5U6zt1e8vNDy6 C31vM55oORZJ5p9KJ6yq6F6PLdjQnn99frAiijzJXohts7t8DlkiIEJ0U88nuCqfAvEB+5f QxqUqM2gnxBQxQZOVB4Fw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:piRc0GeQ6yU=;9fx18nskHfxL9l9yFcxgPfm2nq/ Pq0dpGH3Tp14mtvd95eqDxMPCxpvDe1uTtVTRslO2R+zJaI4qrpTx9hGlkqaMZPVAIZD6TU5g +n5tvsnwTz9FcEor1cZoen56/naiTqtEoXsHC1T0YwMz5rRDFeKCBQjlSVeSlqVxcxHb7vuLF W9wxxFgywkIQ+uGGXHkONMH5PKLZW1DXO967H79fTyqtIcmqvlPSc/bTGLf2+IGw6SJbd1udi T9kv3zmH762ox8y9NyNlhx86ZXlwHSPjAr14BtEeO22RnEsPKu3KotKqr1VRKOYpoLhgsWL/S ISks1QoxgE2yb91jKt403l8m1f1irlTSq7G0WzSIb4zBHrVH8ro8XsyzfSZmW/FVTG3DqFa2X l5xhOtx2VkaJyiVUTRsJoTJEunohNUCppYmjLKZ02lLIWravh2HNhSHUWL6pb3ocU8U4BXxz+ yXYhi+HsMWdrVHGqj2N7eSInpzo6j8jlCLgTV7lPr2h1MhzBAw4TTsBDgLutMoGe+5gShshY2 UYJnKOSoxHdyFljH27Spq7An9o/PiyZhy2gvCfw3qR2QJ6qFaTPShjENV5jQ/KnC4Rnp2IV1z QyaCwuk8a1JoICktaKhryweB5vOG2Uynu06zwESbIrPQlDHjAyWlsQXo/teyjTMdhmbPeG3WE pWetuTI6d+e2bpLkb6QZafAqYDLO/X5pffJp5de7uFiLuHqLr1iheni3yeBvTcQHR7C6cWELI 5GGKaVL3jXD5TvHWTL0ScxLxJTgdoQBerNJrybRvlNxEWLzSSVQvMVc2pqdQcXs3xyWac4v0g uOVYhKp9emZcyuTLssCO1uLVzrCri6nf29N1ksgFokGR42Khsyh/TNiQN0AiJlnprI2SxJy5T ELxb8aCDihkQU8dqcguXyxU5oSxVsNsNW1XLCHPqCvJLmDcBuLl/iU2bgHHP2FYX87eCXrjnz I+BqINqGwQDb/72rfqTnezGfUXASZqsUYGjbkLxKFNJmxobsZtEVp1Srg/Yzd/4+W7XiNhx78 elAMJQyR8KDgri6GGsuAdHlD5tR6rHQ24lNPHe/ltNJ0Q90DYVACzRc0ITZriEMhe1Sz+cWG/ ReB9jNff4H6TdL6GsrSk+Ucmq5ExgkDOJRPysW9s5M7IwtsiMGSbmHG/wboLcSWxvCu07/VJj QSIgpuSRlvhzBf1kwCEgEMnj5S2zC71aY20Th/UAMd63m/2KiH6UbzjWwpW7olv0I9KQ7D78L rqVk0V2huzW0TzFcr04Kd1dXdTBkoioARcyF2MI3fm1SN3yOMCdUrXtD1EglraBo34DGMklCO rQ0c3GIGdm4yNCAT5SwTe8BvUbZrEjdk/ZMq4iBFDjHgapEb3PB6o2Gdwcd5Nq6iHZx9S09sx PCUdZGwHWNSyBiixj1TuzllZ7w+hseBTxb/TVx7w4Cxf+qoqvapqR+eiAY+afm37NkZsOxRnO aY91GcNBJcdopolC1MYC77Fz3tv+OF2qu9TQbTlaqLBkgFFoIb7eYDrhX3Rld96WZucoChBwl 60C8+e16NzuRcLWLh8jUy13ePP/nnagzuWJ6DERFkPyr3fm83grS2jd382M6i8di3gdxaD5hB KVOvdb30zQteB0lBoGG7cM6p48bdwF2Go1snc9mX9tu0M9MuPOsf9GPsdlargJUbtWQSNnYTN Gri4AnLeqcEHHmcPz7mQa6p9Deuv4ouEgAmZAXHF6114ze7PwvQijb/WozkH2j3daVfHAYAhD MIzlnIQlvm+ohXELnLjuQOmsIVEJLFpD0NwjT89Ct0DhTN49ozK49SsUmLpIizrmAB9c6LPDR amJefcK4Qn/LPzY72bX900k+agKJFZkB2GyI7ifDtIVmjr+zW23oWRvDLoqRhOtZp0eBOmEDp PhG5tsrfsRf13mgoawg6NA3c4oZuvmtDroNCOkd7ObLgD6J7QodfGzF97AyIXFV2AliNU0jgR T+GkpFzgKAwMXFLdhLTYm2csBlV2SldbJAyx4DwVzlRQ6oPFmf2SbPKhborE4WvCkpu7a2IIV JKnfYbe/OaS0uOss9mwy/NIjFUuGLjuxh8EgVolyjmyiXEpp0KUGZMiFS87Td2rc6e75gXQi2 XUvKqQDet6jfH87bfVk6HCaQSutiK5cwFnuWugDWuEwRvX9ne9KJF1r5GHCV4mMxRIzO7VQpj gf2lm3Bpd5Y2A2rdo06/hQITiMtpJdQqJJo9//VERivAUz2JdLwDLZY6+0UwK+9xYnb4eZXr4 TDE4a4slLaYbvyJRoJkdyuHSCx0X1SbKXmWQlmJqT5lEEwctbz6hScj0JRtDV3rrhS/o9mcGL W6NckTOpuyEdHd+8VsRvsErcYBVzJMvhFF9xkmDAahidVwON86ontstWJTn/fKFCGIzhrsi20 mxwVKJPepykWkgGh8RmhQuuCvuYra2O4t0v1sDIaz1txRxeoBFEX63M6v+XgtDDayjGHU+Pr6 U0gnWl8EpDIf4xmMhPnKUsfyv8GXVGSnJzOn7lgBdq/bHFVYzgL7YFDGZAdDyg0xxLqKrbxk/ 7NI/X9O0Zkzot40hkIbta7m3a5bAD1zPKdnoRF0LZQ+wJuhy/pbCCIlv2CEeMwxRxG7zPlHae 0y4mSjoJVtyqG30v8KF5ouUjmk0E1IYllwFffd7HwrtkApu+EmUkDsv+g/RyOKeN/tH8qZEJk RitsbypjU/KhqGHSd/ithcllIYNDcofsMtPMysCwzqcqK72NwKmBOtE/Fu4D6wfP1CK7lJk1Z 1oxBWysQX00EUd6IuVjR9zhwTsd8fX+eIKsZBB90iCFkQUte31nc4L1NoWTtK42bEhnLNurYp 4+xkucqE7cIK8fJZ6Fbtw1jPIFvDGI9uhQRUs6cayc2A1GY2nXkxtR35AjHNNjWQi2Uga6LX7 DZOhLFWL1NrBJQddq+o/9ouC5NsrpqjuXJoffvtcXT8GOYe4uWeBBNJHeI9NsISsHF2gF5/gm zYY0ZvruCVwSRbJKK2LBHswFcnJkZnR7uHybKf1uFBOxbkWfLSJpBbotv42pI2/7TSDQW/5aY UTTJhIssl1rd8YRTexMEGfJyooPmlFmcD8Y5/nbslP+f8GYt1kFWZuRFoK/8wlLKsToGtqaN8 xIGdklixopKm98LB3IeWrDMrJXZoEENEuE9w/CzpTZwMez3kMEZ+KtCkbjUAVgWpg0HRwAY83 zJk5kpkcSDtHXwpia7otu8EyRXOXnqY1OF7peVBc73XmrWIAdpyLDgA3KlwZS+Q+p4mHxCaZi Vl/+BzrR2Euc5aeNzqQAVmQLtZzip/KeAJV/jlse9jXm0AL3btsUT74SPZ+lzSqQOc9yeIsnP 0D5asuoTWqDadxm9pTfpPx7IrpCqgAlfFLTdht1/dX6MNpX5go= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78608 Cc: monnier@iro.umontreal.ca, 78608@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.7 (-) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 29 May 2025 09:14:26 +0300 Eli Zaretskii wrote: >> From: Stephen Berman >> Cc: Stefan Monnier , 78608@debbugs.gnu.org >> Date: Thu, 29 May 2025 00:58:22 +0200 >>=20 >> On Wed, 28 May 2025 21:28:22 +0300 Eli Zaretskii wrote: >>=20 >> > Stephen, would you mind explaining in more detail what in that commit >> > caused the regression on the master branch? I'd like us all to be on >> > the same page before we decide how (and whether) to document it. >>=20 >> Unfortunately, I have been unable to step through `setq-local' with >> Edebug when the variable `todo-categories' gets set; typing `i' just >> returns me to todo-read-category after the variable gets set. So I onl= y >> see what I reported in the bug report, which I repeat here for >> convenience: >>=20 >> "Th[e] difference between emacs-30 and master manifests itself in the >> function `todo-category-completions' (called from `todo-read-category') >> around the following code: >>=20 >> (with-current-buffer (find-file-noselect f 'nowarn) >> [...] >> (todo-mode) >> [...]) >>=20 >> In both master and emacs-30, before entering this sexp, the buffer-loca= l >> value of `todo-categories' is nil, but after invoking `todo-mode' its >> value (for the buffer visiting the Todo file `f') becomes non-nil. >> After leaving the `with-current-buffer' form, `todo-categories' retains >> its non-nil value in master, but reverts to nil in emacs-30. The mode >> function `todo-mode' calls `todo-modes-set-3', which contains the form >> `(setq-local todo-categories (todo-set-categories))'. This led me to >> commit f3e0bdf1b98, and indeed, when I undo that change in master, the >> problematic prompt on calling `todo-jump-to-category' does not happen." > > Yes, that was my understanding, and the reason why I thought this > change might affect other Lisp programs. > > Stefan, does the above explain/describe the change in behavior of > setq-local in let-bound code, and is it the change you expect from the > changes you installed? > >> Can either of you tell me how to debug `setq-local' or what to look for >> in the `with-current-buffer' form to try and find the cause of the >> difference between master and emacs-30? > > I hope Stefan will be able to help you there. But the first thing I'd > try when Edebug doesn't help is printf-debugging, i.e. using 'message' > to display values during execution. Did you try that? I haven't tried that yet but in the attached file I've distilled the todo-mode code involved in this issue, making it easier to see what causes the different results with `setq-local' in master and emacs-30: 0. Start emacs from master with -Q. 1. Load the attached file. 2. Type `M-x srb-do RET'. =3D> Now *Messages* contains the following: srb-val 1: nil srb-val 2: 42 srb-val 3: 42 Yes! 3. Kill emacs, visit the attached file and in the function `srb-set-val' comment out the line `(setq srb-val 42)' and uncomment the following line, so it becomes `42'. Type `C-x C-s'. 4. Repeat steps 0-2. =3D> Now *Messages* contains the following: srb-val 1: nil srb-val 2: 42 srb-val 3: nil No! Now repeat the above recipe with emacs-30 -Q: the results in *Message* after steps 2 and 4 are the same: srb-val 1: nil srb-val 2: 42 srb-val 3: nil No! In short: with `setq-local' in master, if you do this: (setq-local var (setq var val)) within a `with-current-buffer' form, then `val' survives after exiting the form, but not if you do this: (setq-local var val) In emacs-30, `val' does not survive in either case. I think this difference is what Stefan was referring by "can occasionally affect code in surprising ways if the computation of the value refers to the variable." But Stefan, when you said you failed to "figure out what was the specific origin of the problem" in the todo-mode case, did you mean something else than using `setq' within `setq-local'? Steve Berman --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=srb.el Content-Transfer-Encoding: quoted-printable ;; srb.el -*- lexical-binding: t; -*- (defvar srb-val nil) (defun srb-do () (interactive) (srb-test) (message "%s" (if srb-val "Yes!" "No!"))) (defun srb-test () (let ((srb-buf (generate-new-buffer "srb-test"))) (with-current-buffer srb-buf (message "srb-val 1: %S" srb-val) (unless (derived-mode-p 'srb-mode) (srb-mode)) (message "srb-val 2: %S" srb-val)) (message "srb-val 3: %S" srb-val))) (defun srb-set-val () (setq srb-val 42) ;; 42 ) (define-derived-mode srb-mode special-mode (setq-local srb-val (srb-set-val))) (provide 'srb) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat May 31 12:51:10 2025 Received: (at 78608) by debbugs.gnu.org; 31 May 2025 16:51:10 +0000 Received: from localhost ([127.0.0.1]:59410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLPQL-0000zl-2r for submit@debbugs.gnu.org; Sat, 31 May 2025 12:51:10 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62662) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLPQI-0000yJ-90 for 78608@debbugs.gnu.org; Sat, 31 May 2025 12:51:06 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B428E440AB3; Sat, 31 May 2025 12:51:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748710259; bh=vHGZQfua6aOTSCv2LFhDodlJdQLL4pSE9RLfJIe7nEw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=e0lX98LYEcuLjIqopuKuPWfj0MtbCMGLp6jIZAE+w1HANPoPlMmsR5oQb9zJGqJMr syQoaMjSi53LMCyGm+hWElbMEEyXNUh+HhBP57R3XH7THOYFc87NWl129WdgvGvq7b PrdXulWGuVAsPYssT+Wi6bKsifAzq14A8d6BNEUvG2GrPtUvin+M2uyPKGKoDJbfDp 9mr1xvy/g6YDabJBVFYRwmA+rGfb5X60QBJloCAqlE1M1k09i0TngV3o8yk4tN71H0 +l0iO8bw8YIChG7ojmVgqKIX8nrjIzULIesWrXzxxRzVYYqM3Zajy4aW9dJipGlblb AiSPG26cM9CzQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 66EFE440A6A; Sat, 31 May 2025 12:50:59 -0400 (EDT) Received: from alfajor (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 80E01120370; Sat, 31 May 2025 12:50:58 -0400 (EDT) From: Stefan Monnier To: Stephen Berman Subject: Re: bug#78608: 31.0.50; Todo mode bug revealed by setq-default change In-Reply-To: <87ikljt4nm.fsf@gmx.net> Message-ID: References: <87y0uif3t7.fsf@gmx.net> <86zfexvws2.fsf@gnu.org> <86bjrcwx2p.fsf@gnu.org> <865xhkwpx5.fsf@gnu.org> <87tt54bawh.fsf@gmx.net> <86y0uguenx.fsf@gnu.org> <87ikljt4nm.fsf@gmx.net> Date: Sat, 31 May 2025 12:50:57 -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.348 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: 78608 Cc: Eli Zaretskii , 78608@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 (---) > In short: with `setq-local' in master, if you do this: > > (setq-local var (setq var val)) > > within a `with-current-buffer' form, then `val' survives after exiting > the form, but not if you do this: > > (setq-local var val) > > In emacs-30, `val' does not survive in either case. I think this > difference is what Stefan was referring by "can occasionally affect code > in surprising ways if the computation of the value refers to the > variable." In the original problem that prompted the fix to `setq-local`, I think there was no `setq` involved, but "refers to the variable" is probably too vague (and suggests that merely asking for the var's value could also be affected, which I believe is not the case). So maybe: ... can occasionally affect code in surprising ways if the computation of the value itself modifies the variable. where "modifies" could be a `defvar`, `setq`, `let`, ... > But Stefan, when you said you failed to "figure out what was the > specific origin of the problem" in the todo-mode case, did you mean > something else than using `setq' within `setq-local'? No, the "`setq' within `setq-local'" is the part that I failed to figure out, thanks. Stefan