From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Oct 2024 17:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 74091@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.173022283414755 (code B ref -1); Tue, 29 Oct 2024 17:28:02 +0000 Received: (at submit) by debbugs.gnu.org; 29 Oct 2024 17:27:14 +0000 Received: from localhost ([127.0.0.1]:57580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5pzu-0003pv-4K for submit@debbugs.gnu.org; Tue, 29 Oct 2024 13:27:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:52432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5pzs-0003pp-3C for submit@debbugs.gnu.org; Tue, 29 Oct 2024 13:27:12 -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 1t5pzr-0006su-2d for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 13:27:11 -0400 Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t5pzp-0006tG-7j for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 13:27:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1730222828; bh=ltWUgFBi6BmQxRWVlZwcPFVNCrpAB8F3FQqbv5z6ofs=; h=From:To:Subject:Date:From; b=lbHyZNsNQkySduqTSsL1353iF4tJ1hOhC8y+pEJq7e89BvM4qBoKmrRhEZjKLE4OG cmEXTIStB9opzQk+We+zpvEuhAwsZ1JRX0BiGhLSLFMHPf7mvl2BlwvzxbKcLcfOUp TDCNLxlwm1D/Ryz4gtQ5zfb/MkOUWgc89a74wqkdLgFl2DQmO95PrEm8vtzDBn6bju KCNhcMYBimemy/Iq9U7uhQtghyR8AQFBrtBtR5nUGbjLMcDFdYoP8diE7A61qwU+yE +iIjvnKNaypXKFsIghGipbUK6DkSuBOf4LnwRFzdukvPgdIz0M7z9dNzlqvTX/c3n/ 8jmzZgxdY89mQ== From: Eshel Yaron X-Hashcash: 1:20:241029:bug-gnu-emacs@gnu.org::fYQmjddbItvU+RgQ:8/mj Date: Tue, 29 Oct 2024 18:27:05 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) 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.4 (--) The new implementation of string-pixel-width has some unexpected effect when it is called from mode-line-format, as happens for example when mode-line-format-right-align occurs in mode-line-format: 1. emacs -Q 2. (setq-default mode-line-format '("" (:eval (progn (string-pixel-width "foo") nil)))) 3. C-x C-f /path/to/emacs/lisp/subr.el 4. C-SPC 5. C-n At this point the region is expected to be active since we activated it in step 4. But in step 5 the mode line is updated, which calls string-pixel-width, which in turn unexpectedly disables the region. I'm not really sure why this happens... Also, if I now trace string-pixel-width, then it no longer disables the region and everything starts working as expected. Thanks, Eshel From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Oct 2024 15:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eshel Yaron Cc: 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173030040018643 (code B ref 74091); Wed, 30 Oct 2024 15:00:03 +0000 Received: (at 74091) by debbugs.gnu.org; 30 Oct 2024 15:00:00 +0000 Received: from localhost ([127.0.0.1]:35512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6AAy-0004qd-DD for submit@debbugs.gnu.org; Wed, 30 Oct 2024 11:00:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6AAw-0004qX-3s for 74091@debbugs.gnu.org; Wed, 30 Oct 2024 10:59:58 -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 1t6AAq-0006xX-DY; Wed, 30 Oct 2024 10:59: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=optbKjRTKQttxQYger8nwd/L1td97vD2dRHPt1QiyJM=; b=Mw0X8RS+iM5g 5iH3G3IQ18DqUq7/AE8WYI7mFXdFu4NI0+GPm9lE1bsIOnn7lm+F1dGogu+zM2lZ3rHPDFWtGLhGD cm3Xgrak8NpaIE3pW1nZn3fjkjpjke+HTI9vzKKtH85P8Ym/UfAAFWIDo3TXsLXSQqmVQVBflU1+7 Wm2B1LZPiuQV5Mygxzd3FgV0m4HXGAgBmQkFfyogs6QVr/zFSjQ2OzszE7zCxNs/G4Dz3UzQU3IKd 9Op6JqIa/R7Zg2VPC+XnIbf6a5oqMyDQypwWRQF8lqBlwlnow1wCKDJgZcM239QiyGx42xFd9T1z7 zsomVecDLxnIKD41dzajLw==; Date: Wed, 30 Oct 2024 16:59:49 +0200 Message-Id: <86y1254owq.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (bug-gnu-emacs@gnu.org) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 29 Oct 2024 18:27:05 +0100 > From: Eshel Yaron via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > > > The new implementation of string-pixel-width has some unexpected effect > when it is called from mode-line-format, as happens for example when > mode-line-format-right-align occurs in mode-line-format: > > 1. emacs -Q > 2. (setq-default mode-line-format > '("" (:eval (progn (string-pixel-width "foo") nil)))) > 3. C-x C-f /path/to/emacs/lisp/subr.el > 4. C-SPC > 5. C-n > > At this point the region is expected to be active since we activated it > in step 4. But in step 5 the mode line is updated, which calls > string-pixel-width, which in turn unexpectedly disables the region. Thanks, should be fixed now. > I'm not really sure why this happens... It happens because string-pixel-width modifies a buffer, and that sets deactivate-mark, which then causes the region to be deactivated when a command finishes. When you inject string-pixel-width into mode-line-format, you indirectly cause it to be called from C-n and the like, because those evaluate the mode-line format. So doing that is quite a risky thing, in general. From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Oct 2024 15:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173030200422655 (code B ref 74091); Wed, 30 Oct 2024 15:27:01 +0000 Received: (at 74091) by debbugs.gnu.org; 30 Oct 2024 15:26:44 +0000 Received: from localhost ([127.0.0.1]:35659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6Aaq-0005tL-4e for submit@debbugs.gnu.org; Wed, 30 Oct 2024 11:26:44 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:53128 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6Aan-0005tE-Hv for 74091@debbugs.gnu.org; Wed, 30 Oct 2024 11:26:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1730302001; bh=QM63yKUKR6FVmkA6IQ/KTCG7itf8/cqWHLtcq6XAAeM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G1GLvisLLo93w7fNGm0P1dFociCAL9DKFuWT4f1GEH25aIR72g4oAq2wgVWKJJJ8u 1r0NpXTMsHqEbYzwSGNVbbirIDC4agF/S+r+jGY6r7Y4CRU4EBlJFMhY+5wpOzJQRM gn+sbCpW/GvxsoJIvsu3ipENzYTD+T9OGRCY2cZy9vRl0c7rR6dv76f4j0u1v9lopo OxeFd7g+aU+HKQ96fUmt84nYj+Agb7JRPmL+UU73wKOcNNCflyvkFdwUbpEtpZbk2m fpUnnf3sNiyVuQyAsfcNMrD1K0eCKncgpcS60TK+aFUjapdrT+YW9ZjseWyfMJQKKS 0+FbEVKD4We5g== From: Eshel Yaron In-Reply-To: <86y1254owq.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Oct 2024 16:59:49 +0200") References: <86y1254owq.fsf@gnu.org> X-Hashcash: 1:20:241030:eliz@gnu.org::3mo8tRZk75AhQVgb:1XKP X-Hashcash: 1:20:241030:74091@debbugs.gnu.org::O1FrrTNAxUk+ReEq:0vcC Date: Wed, 30 Oct 2024 16:26:38 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Eli, Eli Zaretskii writes: >> Date: Tue, 29 Oct 2024 18:27:05 +0100 >> From: Eshel Yaron via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> >> >> The new implementation of string-pixel-width has some unexpected effect >> when it is called from mode-line-format, as happens for example when >> mode-line-format-right-align occurs in mode-line-format: >> >> 1. emacs -Q >> 2. (setq-default mode-line-format >> '("" (:eval (progn (string-pixel-width "foo") nil)))) >> 3. C-x C-f /path/to/emacs/lisp/subr.el >> 4. C-SPC >> 5. C-n >> >> At this point the region is expected to be active since we activated it >> in step 4. But in step 5 the mode line is updated, which calls >> string-pixel-width, which in turn unexpectedly disables the region. > > Thanks, should be fixed now. Great! That seems to work. >> I'm not really sure why this happens... > > It happens because string-pixel-width modifies a buffer, and that sets > deactivate-mark, which then causes the region to be deactivated when > a command finishes. Hmm but string-pixel-width used to modify a buffer also in the old implementation, and that never caused this issue... And in both the old implementation and in the new one, the modification is in a different buffer, is that expected to disable the mark in the original buffer? > When you inject string-pixel-width into mode-line-format, you > indirectly cause it to be called from C-n and the like, because those > evaluate the mode-line format. So doing that is quite a risky thing, > in general. Well, that's how Emacs implements mode-line-format-right-align :) Thanks for the quick response, Eshel From unknown Sun Jun 22 00:44:21 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eshel Yaron Subject: bug#74091: closed (Re: bug#74091: 31.0.50; string-pixel-width in mode line disables region) Message-ID: References: <86ldy54m2g.fsf@gnu.org> X-Gnu-PR-Message: they-closed 74091 X-Gnu-PR-Package: emacs Reply-To: 74091@debbugs.gnu.org Date: Wed, 30 Oct 2024 16:02:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1730304122-27511-1" This is a multi-part message in MIME format... ------------=_1730304122-27511-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #74091: 31.0.50; string-pixel-width in mode line disables region which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 74091@debbugs.gnu.org. --=20 74091: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D74091 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1730304122-27511-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 74091-done) by debbugs.gnu.org; 30 Oct 2024 16:01:23 +0000 Received: from localhost ([127.0.0.1]:35869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6B8N-00078z-5K for submit@debbugs.gnu.org; Wed, 30 Oct 2024 12:01:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6B8K-00078s-Cx for 74091-done@debbugs.gnu.org; Wed, 30 Oct 2024 12:01:22 -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 1t6B8E-0008Pl-R1; Wed, 30 Oct 2024 12:01:14 -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=ojaqy+ho3o4JZ2/xPmk/KTPi8b9fAYJ21flVNm8TEno=; b=LS1pcVbnAHyT mQHyjJX6BOEmHw9UTa4OGbAC6UfukURILFtTMD6kcZ0kDU4qrHb3l5BFctekbdtq4inJgLPjr0AOI ytDLDzhPT3DRcvlevePpNSnTPSfSa+vHYoBj5vLgxqOZvOkas89eJnu/ZfKxQ9ctq22fWtNl4Rqhg 43FmRsCqdAFWO4NuAmR+2mfpEJp/rwGtsKIo1I4I0iRw72Odc2blR2abVsx19GT8cJ+82rhzrEeDA K1OEePhdy9bnVk7nqjZu7/Fkz1RGl6BKsxatrLJgKJjtTbjqAyzftzmj53Bor+kAaUlr0BxtQFjD5 gEHwtdWkxxTcNRrwB6ojpw==; Date: Wed, 30 Oct 2024 18:01:11 +0200 Message-Id: <86ldy54m2g.fsf@gnu.org> From: Eli Zaretskii To: Eshel Yaron In-Reply-To: (message from Eshel Yaron on Wed, 30 Oct 2024 16:26:38 +0100) Subject: Re: bug#74091: 31.0.50; string-pixel-width in mode line disables region References: <86y1254owq.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 74091-done Cc: 74091-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: -3.3 (---) > From: Eshel Yaron > Cc: 74091@debbugs.gnu.org > Date: Wed, 30 Oct 2024 16:26:38 +0100 > > >> At this point the region is expected to be active since we activated it > >> in step 4. But in step 5 the mode line is updated, which calls > >> string-pixel-width, which in turn unexpectedly disables the region. > > > > Thanks, should be fixed now. > > Great! That seems to work. Thanks for testing, I will close this bug. > >> I'm not really sure why this happens... > > > > It happens because string-pixel-width modifies a buffer, and that sets > > deactivate-mark, which then causes the region to be deactivated when > > a command finishes. > > Hmm but string-pixel-width used to modify a buffer also in the old > implementation, and that never caused this issue... The new implementation also didn't cause this issue in some buffers. For example, in *scratch*. Trying to understand the logic of a bug is never a good investment of time. > And in both the old > implementation and in the new one, the modification is in a different > buffer, is that expected to disable the mark in the original buffer? The variable deactivate-mark only becomes buffer-local if set; otherwise the global value will be changed. > > When you inject string-pixel-width into mode-line-format, you > > indirectly cause it to be called from C-n and the like, because those > > evaluate the mode-line format. So doing that is quite a risky thing, > > in general. > > Well, that's how Emacs implements mode-line-format-right-align :) One reason why I don't like it. mode-line-format is evaluated in many more contexts than most people realize, so putting arbitrary calls there without a good understanding what those calls do and how is not the best idea, although it will mostly work. ------------=_1730304122-27511-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 29 Oct 2024 17:27:14 +0000 Received: from localhost ([127.0.0.1]:57580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5pzu-0003pv-4K for submit@debbugs.gnu.org; Tue, 29 Oct 2024 13:27:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:52432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5pzs-0003pp-3C for submit@debbugs.gnu.org; Tue, 29 Oct 2024 13:27:12 -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 1t5pzr-0006su-2d for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 13:27:11 -0400 Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t5pzp-0006tG-7j for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2024 13:27:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1730222828; bh=ltWUgFBi6BmQxRWVlZwcPFVNCrpAB8F3FQqbv5z6ofs=; h=From:To:Subject:Date:From; b=lbHyZNsNQkySduqTSsL1353iF4tJ1hOhC8y+pEJq7e89BvM4qBoKmrRhEZjKLE4OG cmEXTIStB9opzQk+We+zpvEuhAwsZ1JRX0BiGhLSLFMHPf7mvl2BlwvzxbKcLcfOUp TDCNLxlwm1D/Ryz4gtQ5zfb/MkOUWgc89a74wqkdLgFl2DQmO95PrEm8vtzDBn6bju KCNhcMYBimemy/Iq9U7uhQtghyR8AQFBrtBtR5nUGbjLMcDFdYoP8diE7A61qwU+yE +iIjvnKNaypXKFsIghGipbUK6DkSuBOf4LnwRFzdukvPgdIz0M7z9dNzlqvTX/c3n/ 8jmzZgxdY89mQ== From: Eshel Yaron To: bug-gnu-emacs@gnu.org Subject: 31.0.50; string-pixel-width in mode line disables region X-Debbugs-Cc: X-Hashcash: 1:20:241029:bug-gnu-emacs@gnu.org::fYQmjddbItvU+RgQ:8/mj Date: Tue, 29 Oct 2024 18:27:05 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) 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: -2.4 (--) The new implementation of string-pixel-width has some unexpected effect when it is called from mode-line-format, as happens for example when mode-line-format-right-align occurs in mode-line-format: 1. emacs -Q 2. (setq-default mode-line-format '("" (:eval (progn (string-pixel-width "foo") nil)))) 3. C-x C-f /path/to/emacs/lisp/subr.el 4. C-SPC 5. C-n At this point the region is expected to be active since we activated it in step 4. But in step 5 the mode line is updated, which calls string-pixel-width, which in turn unexpectedly disables the region. I'm not really sure why this happens... Also, if I now trace string-pixel-width, then it no longer disables the region and everything starts working as expected. Thanks, Eshel ------------=_1730304122-27511-1-- From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Oct 2024 11:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 74091-done@debbugs.gnu.org Received: via spool by 74091-done@debbugs.gnu.org id=D74091.173037296616309 (code D ref 74091); Thu, 31 Oct 2024 11:10:01 +0000 Received: (at 74091-done) by debbugs.gnu.org; 31 Oct 2024 11:09:26 +0000 Received: from localhost ([127.0.0.1]:41661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6T3N-0004Ez-NM for submit@debbugs.gnu.org; Thu, 31 Oct 2024 07:09:26 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:46426 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6T3L-0004En-Ij for 74091-done@debbugs.gnu.org; Thu, 31 Oct 2024 07:09:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1730372963; bh=TRym44UnC+qVCurLZ+wiM3PqKLhUtwbZZxF4Bz0ulL4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Tqzute+5VO7+LahDb/SxA+Rj6MKSPuzduEs6Y5ZPHaiD7AmFSTdHbDJN+qUaVPvmB oQ1RfhcMTOwd2i566EJm5gkVz6qCaRW/i4o1uKNKFj2sxO6aMGzhEqDQZWdXm13t27 w5IOJhskkbfXHcQDQnKfI+lE5g5KJCGoGHWoB/5rsTKmdxYxbnyBClbWMTQL1jJvnM GQlUZGDlKibLMTYdiL3RkNbZS7kVXb469ronMO3ba8u/P7icO2g3YCtbkvoCP/fCLr N11CWneUnD8vDUfbSLP7MwbrISpnklhUYoNE8WUIXeNS9IG5b3e1Y1sipgN0ZLyTtH 9X4hVQvlsSpZw== From: Eshel Yaron In-Reply-To: <86ldy54m2g.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Oct 2024 18:01:11 +0200") References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> Date: Thu, 31 Oct 2024 12:09:20 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: 74091@debbugs.gnu.org >> Date: Wed, 30 Oct 2024 16:26:38 +0100 >> >> >> At this point the region is expected to be active since we activated it >> >> in step 4. But in step 5 the mode line is updated, which calls >> >> string-pixel-width, which in turn unexpectedly disables the region. >> > >> > Thanks, should be fixed now. >> >> Great! That seems to work. > > Thanks for testing, I will close this bug. Since we don't fully understand the issue, it may manifest in more ways. So I think closing the bug is premature. After looking a bit more into it, it seems like the problem has to do with the call to kill-all-local-variables in work-buffer--release, the following patch circumvents the unexpected behavior, although I still don't understand why: diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el index 5b47deb880e..b5cbe28afad 100644 --- a/lisp/emacs-lisp/subr-x.el +++ b/lisp/emacs-lisp/subr-x.el @@ -361,7 +361,7 @@ work-buffer--release (erase-buffer)) (delete-all-overlays) (let (change-major-mode-hook) - (kill-all-local-variables t)) + (kill-all-local-variables)) ;; Make the buffer available again. (push buffer work-buffer--list))) ;; If the maximum number of reusable work buffers is exceeded, kill Here's another interesting data point: --8<---------------cut here---------------start------------->8--- (defun foo () (interactive) (with-current-buffer (get-buffer-create "some-buffer") (kill-all-local-variables t) (insert "foo"))) --8<---------------cut here---------------end--------------->8--- Invoking this command twice in a row in subr.el deactivates the region, while the same without the argument to kill-all-local-variables keeps the region active. So the problem seems to be in a lower level than string-pixel-width... >> >> I'm not really sure why this happens... >> > >> > It happens because string-pixel-width modifies a buffer, and that sets >> > deactivate-mark, which then causes the region to be deactivated when >> > a command finishes. >> >> Hmm but string-pixel-width used to modify a buffer also in the old >> implementation, and that never caused this issue... > > The new implementation also didn't cause this issue in some buffers. > For example, in *scratch*. Trying to understand the logic of a bug is > never a good investment of time. :) As I'm sure you know, applying a crude fix without fully understanding the problem is likely to hide other subtle bugs that may then be harder to investigate. >> And in both the old >> implementation and in the new one, the modification is in a different >> buffer, is that expected to disable the mark in the original buffer? > > The variable deactivate-mark only becomes buffer-local if set; > otherwise the global value will be changed. Could you perhaps elaborate? I see that running a command that modifies a different buffer does not deactivate the region in the current buffer, which is basically what I would expect. Best, Eshel From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Oct 2024 11:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eshel Yaron Cc: 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173037487520675 (code B ref 74091); Thu, 31 Oct 2024 11:42:02 +0000 Received: (at 74091) by debbugs.gnu.org; 31 Oct 2024 11:41:15 +0000 Received: from localhost ([127.0.0.1]:41734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6TYA-0005NP-Nm for submit@debbugs.gnu.org; Thu, 31 Oct 2024 07:41:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59222) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6TY8-0005ND-MY for 74091@debbugs.gnu.org; Thu, 31 Oct 2024 07:41:13 -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 1t6TY2-0007CZ-M2; Thu, 31 Oct 2024 07:41:06 -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=M8xKIG7lNQWfaZ8PnnyAL7fvQpUjcRnaiGukFGzk0ho=; b=QELGnCIlr6i3LaM8WM3N WplNemYOqtKAVH+gxflY90AOIWQKd73jMZoEuwdMekZlSTLVtkvnJM2EHU9g0DJfjqsreRFu1L68P /dpbyGYRgcm5m9kwvmJ5g/pjOE6WUlgthacvDKo89M8BwrLy8ZDq5TT2AUH75f9fp5WNxKDl5T0QH +oatI784UX5gRfdCVSMSC4lYpPrQJVZRADUVMgTS2w7mPxVsHnnpM5HXV/FmcQXfLJURvmJIGFRjG 8iuys0pv0kQaNav05BaaJqBCWlqiI+SM2e9bq10VNMABo5WePwVP4HNmsbvmMubc83QXTm5EslfUX ZLupt8kpVUPZ1Q==; Date: Thu, 31 Oct 2024 13:41:02 +0200 Message-Id: <86ed3w33g1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Eshel Yaron on Thu, 31 Oct 2024 12:09:20 +0100) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Eshel Yaron > Cc: 74091-done@debbugs.gnu.org > Date: Thu, 31 Oct 2024 12:09:20 +0100 > > Invoking this command twice in a row in subr.el deactivates the region, > while the same without the argument to kill-all-local-variables keeps > the region active. > > So the problem seems to be in a lower level than string-pixel-width... Killing local variables makes the global value of deactivate-mark be in effect when the command loop decides whether to deactivate the region after a command finishes. > As I'm sure you know, applying a crude fix without fully understanding > the problem is likely to hide other subtle bugs that may then be harder > to investigate. That's not a crude fix, that's what the ELisp manual tells us to do: -- Variable: deactivate-mark If an editor command sets this variable non-‘nil’, then the editor command loop deactivates the mark after the command returns (if Transient Mark mode is enabled). All the primitives that change the buffer set ‘deactivate-mark’, to deactivate the mark when the command is finished. Setting this variable makes it buffer-local. To write Lisp code that modifies the buffer without causing deactivation of the mark at the end of the command, bind ‘deactivate-mark’ to ‘nil’ around the code that does the modification. For example: (let (deactivate-mark) (insert " ")) > >> And in both the old > >> implementation and in the new one, the modification is in a different > >> buffer, is that expected to disable the mark in the original buffer? > > > > The variable deactivate-mark only becomes buffer-local if set; > > otherwise the global value will be changed. > > Could you perhaps elaborate? I see that running a command that modifies > a different buffer does not deactivate the region in the current buffer, > which is basically what I would expect. You are asking me to elaborate about what? about the local value of deactivate-mark or about why you see what you see (in a scenario you haven't described)? Look, you are welcome to keep debugging this if you are interested. I invested enough of my time into figuring out why the region was deactivated by C-n, and the solution I installed satisfies me. But you are welcome to keep digging, and let me tell you what I found to save you some non-trivial tinkering: . The region is deactivated because of this in our command loop: if (!NILP (Vdeactivate_mark)) /* If `select-active-regions' is non-nil, this call to `deactivate-mark' also sets the PRIMARY selection. */ call0 (Qdeactivate_mark); This is consistent with what the ELisp manual says, see the above citation. . Deactivate-mark is set non-nil by the low-level subroutines that modify the buffer, again according to the manual. Two such buffer-modification calls were present in string-pixel-width: one in string-pixel-width itself, when it inserts the string into a work buffer, the other in work-buffer--release where it erases the work buffer. This happens in in prepare_to_modify_buffer_1: signal_before_change (start, end, preserve_ptr); Fset (Qdeactivate_mark, Qt); . Here is a Lisp-level backtrace from one call which sets deactivate-mark in your recipe, as collected by GDB: Lisp Backtrace: "string-pixel-width" (0x65a8940) "progn" (0x65a8c40) "eval" (0x65a8f90) "posn-at-point" (0xa084200) "line-move-visual" (0xa084170) "line-move" (0xa084108) "next-line" (0x65aea10) "funcall-interactively" (0x65aea08) "call-interactively" (0xa084078) "command-execute" (0x65af798) As you see, next-line calls posn-at-point, which formats the mode line (to calculate is height), and that invokes the :eval form. Here's the C backtrace which captures the details missing from the above Lisp backtrace: Thread 1 hit Hardware watchpoint 4: Vdeactivate_mark Old value = XIL(0) New value = XIL(0x30) 0x00bd2da5 in store_symval_forwarding (valcontents=..., newval=XIL(0x30), buf=0x8f4c48) at data.c:1430 1430 *XOBJFWD (valcontents)->objvar = newval; (gdb) bt #0 0x00bd2da5 in store_symval_forwarding (valcontents=..., newval=XIL(0x30), buf=0x8f4c48) at data.c:1430 #1 0x00bd3da3 in set_internal (symbol=XIL(0x6210), newval=XIL(0x30), where=XIL(0xa0000000008f4c48), bindflag=SET_INTERNAL_SET) at data.c:1759 #2 0x00bd37c5 in Fset (symbol=XIL(0x6210), newval=XIL(0x30)) at data.c:1630 #3 0x00b5b757 in prepare_to_modify_buffer_1 (start=1, end=1, preserve_ptr=0x0) at insdel.c:2073 #4 0x00b5b784 in prepare_to_modify_buffer (start=1, end=1, preserve_ptr=0x0) at insdel.c:2083 #5 0x00b57e1b in insert_from_string_1 (string=XIL(0x800000000bc07ad8), pos=0, pos_byte=0, nchars=3, nbytes=3, inherit=false, before_markers=false) at insdel.c:1023 #6 0x00b57c15 in insert_from_string (string=XIL(0x800000000bc07ad8), pos=0, pos_byte=0, length=3, length_byte=3, inherit=false) at insdel.c:974 #7 0x00be5dbf in general_insert_function (insert_func=0xb57249 , insert_from_string_func=0xb57b92 , inherit=false, nargs=1, args=0xa084250) at editfns.c:1336 #8 0x00be5e59 in Finsert (nargs=1, args=0xa084250) at editfns.c:1372 #9 0x00c71edc in exec_byte_code (fun=XIL(0xa0000000008f45b0), args_template=513, nargs=1, args=0x65a8948) at bytecode.c:1417 #10 0x00c019a3 in funcall_lambda (fun=XIL(0xa0000000008f45b0), nargs=1, arg_vector=0x65a8940) at eval.c:3238 #11 0x00c017be in apply_lambda (fun=XIL(0xa0000000008f45b0), args=XIL(0xc00000000071c2d0), count=640) at eval.c:3201 #12 0x00bff56b in eval_sub (form=XIL(0xc00000000071c2e0)) at eval.c:2631 #13 0x00bf7cde in Fprogn (body=XIL(0xc00000000071c2b0)) at eval.c:439 #14 0x00bfec17 in eval_sub (form=XIL(0xc00000000071c2f0)) at eval.c:2535 #15 0x00bfe644 in Feval (form=XIL(0xc00000000071c2f0), lexical=XIL(0x30)) at eval.c:2448 #16 0x00c010df in funcall_subr (subr=0x128a1c0 , numargs=2, args=0x65a8f90) at eval.c:3149 #17 0x00c00a02 in funcall_general (fun=XIL(0xa00000000128a1c0), numargs=2, args=0x65a8f90) at eval.c:3026 #18 0x00c00d92 in Ffuncall (nargs=3, args=0x65a8f88) at eval.c:3079 #19 0x00bfbd5f in internal_condition_case_n (bfun=0xc00c46 , nargs=3, args=0x65a8f88, handlers=XIL(0x30), hfun=0x9dfc51 ) at eval.c:1687 #20 0x009dfd7d in dsafe__call (inhibit_quit=true, f=0xc00c46 , nargs=3, args=0x65a8f88) at xdisp.c:3093 #21 0x009dfef9 in dsafe_eval (sexpr=XIL(0xc00000000071c2f0)) at xdisp.c:3129 #22 0x00a3033e in display_mode_element (it=0x65a93d0, depth=2, field_width=0, precision=0, elt=XIL(0xc00000000071c300), props=XIL(0), risky=false) at xdisp.c:28039 #23 0x00a308f2 in display_mode_element (it=0x65a93d0, depth=1, field_width=0, precision=0, elt=XIL(0xc00000000071c290), props=XIL(0), risky=false) at xdisp.c:28125 #24 0x00a2e976 in display_mode_line (w=0xbb0b428, face_id=MODE_LINE_ACTIVE_FACE_ID, format=XIL(0xc00000000071c310)) at xdisp.c:27550 #25 0x009d54b2 in pos_visible_p (w=0xbb0b428, charpos=1, x=0x65adfec, y=0x65adfe8, rtop=0x65adffc, rbot=0x65adff8, rowh=0x65adff4, vpos=0x65adff0) at xdisp.c:1732 #26 0x00a65e8e in Fpos_visible_in_window_p (pos=XIL(0), window=XIL(0xa00000000bb0b428), partially=XIL(0x30)) at window.c:2018 #27 0x00b2810d in Fposn_at_point (pos=XIL(0), window=XIL(0xa00000000bb0b428)) at keyboard.c:12552 Translation: posn-at-point called pos-visible-in-window-p, , which called pos_visible_p, which called display_mode_line. That eventually called the :eval form, and inserted the string via insert_from_string_1, which called prepare_to_modify_buffer_1, which set deactivate-mark to t. That's what I saw and what led me to my solution, according to what the ELisp manual says. From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Oct 2024 12:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173037748126196 (code B ref 74091); Thu, 31 Oct 2024 12:25:02 +0000 Received: (at 74091) by debbugs.gnu.org; 31 Oct 2024 12:24:41 +0000 Received: from localhost ([127.0.0.1]:41843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6UED-0006oS-2I for submit@debbugs.gnu.org; Thu, 31 Oct 2024 08:24:41 -0400 Received: from mail.eshelyaron.com ([107.175.124.16]:45830 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6UEA-0006oK-P7 for 74091@debbugs.gnu.org; Thu, 31 Oct 2024 08:24:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1730377478; bh=KqBX5a5EB/2fK6WHJ4+PZIyNQy1M6K+PYRdtIrqYcVk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YWX88i3BFnPbl8M6GAB6NNz3HiaiaNE+0ZGeEgjuPNTwt7/OWUz+cg1NfvfTZX5Y1 fNMszzFr/cgKDneOAH3Iu3k0lIUYMogb+I9Liq4c240nNZbQEhmlxfTt7WzTMRt7+c l/gT5qkjin3jnNZlwxpzreKT2x7emK6XJdm0Y63n/XgYC0+kX5dAkN7/mfVL1k36oH w4xtwmodROsKskslk+eXc+850WC/aCrHsASCXjx9xScyiVRVV+N0E8TmNPYBRupfeo BCiwwWnoE7nkcyGVPiSAiPEzBpOYr2AcZwwOPR/b9McRRtF7w1rQa1gmvRZ3I72xWT lE8zlQB1kK90w== From: Eshel Yaron In-Reply-To: <86ed3w33g1.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 31 Oct 2024 13:41:02 +0200") References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> Date: Thu, 31 Oct 2024 13:24:34 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> > The variable deactivate-mark only becomes buffer-local if set; >> > otherwise the global value will be changed. >> >> Could you perhaps elaborate? I see that running a command that modifies >> a different buffer does not deactivate the region in the current buffer, >> which is basically what I would expect. > > You are asking me to elaborate about what? about the local value of > deactivate-mark or about why you see what you see (in a scenario you > haven't described)? What I'm asking is: under what circumstances is it expected that after changing deactivate-mark in another buffer the mark is deactivated in the current buffer? > Look, you are welcome to keep debugging this if you are interested. I > invested enough of my time into figuring out why the region was > deactivated by C-n, and the solution I installed satisfies me. But > you are welcome to keep digging, and let me tell you what I found to > save you some non-trivial tinkering: Thank you, I'll keep digging and let you know if I figure it out. From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Oct 2024 14:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eshel Yaron Cc: 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173038535611818 (code B ref 74091); Thu, 31 Oct 2024 14:36:01 +0000 Received: (at 74091) by debbugs.gnu.org; 31 Oct 2024 14:35:56 +0000 Received: from localhost ([127.0.0.1]:42357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6WHE-00034Y-B1 for submit@debbugs.gnu.org; Thu, 31 Oct 2024 10:35:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6WHC-00034L-9J for 74091@debbugs.gnu.org; Thu, 31 Oct 2024 10:35:55 -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 1t6WH6-0005v2-Kx; Thu, 31 Oct 2024 10:35:49 -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=Vhaaiz5zFyLVTsJo76OScFaBMMpge5WheZqYW6miBIo=; b=Km4GjlrYZDja NJNSjp6wDh9oFJ808etR0IyJn/CBLFCNpM2Mf2K/yW5D5+NpsrY2LfUafxle0YhzO8n6IN3j9sQ7f 0v30ziMAkbtGMOwK2oxGJKB3pXAuptBeNxBzNPTmiOHNEYf80DqsS5oX2KaNFhubExVMDODXvNFsB 5J9vLrO7aptJHzI7mkx4TWrB09SNMfOPddCYoJucAMjI1uoYy5VQGcwOsiIvl/AY5vgV6o/Au7PFV zriSDAYXaeo3SxGiQO23fpvzy8JqQs20d8AGB7Z/tKXHstJub+3Z+cOK5MQyLdS+UpjxkyUnnxEIN mNB46QLkCR5n8EsR0/nVdQ==; Date: Thu, 31 Oct 2024 16:35:37 +0200 Message-Id: <865xp82vd2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Eshel Yaron on Thu, 31 Oct 2024 13:24:34 +0100) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Eshel Yaron > Cc: 74091@debbugs.gnu.org > Date: Thu, 31 Oct 2024 13:24:34 +0100 > > Eli Zaretskii writes: > > >> > The variable deactivate-mark only becomes buffer-local if set; > >> > otherwise the global value will be changed. > >> > >> Could you perhaps elaborate? I see that running a command that modifies > >> a different buffer does not deactivate the region in the current buffer, > >> which is basically what I would expect. > > > > You are asking me to elaborate about what? about the local value of > > deactivate-mark or about why you see what you see (in a scenario you > > haven't described)? > > What I'm asking is: under what circumstances is it expected that > after changing deactivate-mark in another buffer the mark is deactivated > in the current buffer? AFAIU, whenever deactivate-mark is not local to the buffer which is being changed. > > Look, you are welcome to keep debugging this if you are interested. I > > invested enough of my time into figuring out why the region was > > deactivated by C-n, and the solution I installed satisfies me. But > > you are welcome to keep digging, and let me tell you what I found to > > save you some non-trivial tinkering: > > Thank you, I'll keep digging and let you know if I figure it out. TIA. From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Nov 2024 08:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.17308800846526 (code B ref 74091); Wed, 06 Nov 2024 08:02:02 +0000 Received: (at 74091) by debbugs.gnu.org; 6 Nov 2024 08:01:24 +0000 Received: from localhost ([127.0.0.1]:39156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8ayh-0001hC-Ji for submit@debbugs.gnu.org; Wed, 06 Nov 2024 03:01:23 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:51378 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8ayd-0001gz-00 for 74091@debbugs.gnu.org; Wed, 06 Nov 2024 03:01:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1730880078; bh=dEFzENWglgfyEKs/F7rpVEd9NDUYrDyxX0DIoNyGYiA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DGN6ehAuih2DRYVLnd3LHxfyd/sq4wPChybGiF4EQVsY8NlGVJR+1VcUyRO7Ty9aH QViSoqlFyR9V95Aha56UgRrzP0KT72vcCPO04zdo7uvJ2yoW+HGMdRY6+2GsCsb4C0 7D88F2qYXCDfdzaELKGYz/MPidOO3Ay3q6/qXLc9awB2ajX5sSFP42lXhurbOJLBTp wVViRrZj4sIfY9bYO/S1Xuyp3L0DNQQLxCxNL/0aPfQZXh/TXcj8ddgSX57laBH8Ep cRg8sh6H2+txJaQIU/6qk0vUc4IS5rbWIE9KQDW9lybE7Kq6Qq1fR3DTh5Ga5HK8aA fkBezqNvBSSRA== From: Eshel Yaron In-Reply-To: <865xp82vd2.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 31 Oct 2024 16:35:37 +0200") References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <865xp82vd2.fsf@gnu.org> Date: Wed, 06 Nov 2024 09:01:16 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, Eli Zaretskii writes: >> > Look, you are welcome to keep debugging this if you are interested. I >> > invested enough of my time into figuring out why the region was >> > deactivated by C-n, and the solution I installed satisfies me. But >> > you are welcome to keep digging, and let me tell you what I found to >> > save you some non-trivial tinkering: >> >> Thank you, I'll keep digging and let you know if I figure it out. > > TIA. FYI after spending a bit more time on this issue, I concluded that (kill-all-local-variables t) is inherently problematic: it breaks assumptions that Emacs relies on. (See bug#73005 for another example.) It doesn't seem like killing permanent-local variables in the work buffers is necessary ATM, so the fix I'm using is the following: diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el index 5b47deb880e..b5cbe28afad 100644 --- a/lisp/emacs-lisp/subr-x.el +++ b/lisp/emacs-lisp/subr-x.el @@ -361,7 +361,7 @@ work-buffer--release (erase-buffer)) (delete-all-overlays) (let (change-major-mode-hook) - (kill-all-local-variables t)) + (kill-all-local-variables)) ;; Make the buffer available again. (push buffer work-buffer--list))) ;; If the maximum number of reusable work buffers is exceeded, kill Best, Eshel From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Nov 2024 12:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eshel Yaron Cc: 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173089740622377 (code B ref 74091); Wed, 06 Nov 2024 12:51:01 +0000 Received: (at 74091) by debbugs.gnu.org; 6 Nov 2024 12:50:06 +0000 Received: from localhost ([127.0.0.1]:40006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8fU6-0005or-3s for submit@debbugs.gnu.org; Wed, 06 Nov 2024 07:50:06 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44356) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8fU3-0005oE-LI for 74091@debbugs.gnu.org; Wed, 06 Nov 2024 07:50:04 -0500 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 1t8fTw-0004cH-1i; Wed, 06 Nov 2024 07:49:57 -0500 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=E3pvw3D8k+SS910/APUeT8qUu0zvcwYDVxy90foe+dU=; b=D2hkZW2jX6p2 CNstgWLBb2oj9uMyTxEThZxxC5yQuZHCB2TtzaGX8Uw2mRtOnk3LoNajcC17r3unnDiGsuwvrCFNp SltCsbVZ4Zk4RBkWa1lGO3NSMSgrbmIM+DuKzeWxulpCPBMyQZmUZtk67Uq1USoSAmlzWDE9sPLd4 BeqezppMmieXCG7vP8cuzZtI9Z/hqprww4tjDBLcNEfqgNsC5p7D0yP5Ii4tjFu20I6e4OmO1AN0P +ScKG58iBDFuyOgZ1XPzsZVmRl7+9VDaqVLV/Il28UiQaxfjpTLEsiKAlmjj7NYukPTB9HjIQQgKh dipQdGEVkpsxg7SgQsfWCg==; Date: Wed, 06 Nov 2024 14:49:46 +0200 Message-Id: <86ldxwsf11.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Eshel Yaron on Wed, 06 Nov 2024 09:01:16 +0100) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <865xp82vd2.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Eshel Yaron > Cc: 74091@debbugs.gnu.org > Date: Wed, 06 Nov 2024 09:01:16 +0100 > > FYI after spending a bit more time on this issue, I concluded that > (kill-all-local-variables t) is inherently problematic: it breaks > assumptions that Emacs relies on. (See bug#73005 for another example.) > > It doesn't seem like killing permanent-local variables in the work > buffers is necessary ATM, so the fix I'm using is the following: Can't _any_ variable become permanent-local, by virtue of some Lisp program or the user giving it a permanent-local property? More generally, how do we know that there are no permanent-local variables out there that affect layout, and thus affect the results of this function? I believe these considerations were those which led the author to use kill-all-local-variables like this: we want to be sure that nothing will dupe string-pixel-width into producing unexpected results. From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Nov 2024 14:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.17309023524053 (code B ref 74091); Wed, 06 Nov 2024 14:13:01 +0000 Received: (at 74091) by debbugs.gnu.org; 6 Nov 2024 14:12:32 +0000 Received: from localhost ([127.0.0.1]:40160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8glr-00013I-Vn for submit@debbugs.gnu.org; Wed, 06 Nov 2024 09:12:32 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:38384 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8glp-000137-9D for 74091@debbugs.gnu.org; Wed, 06 Nov 2024 09:12:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1730902348; bh=PZo5G1unwen+VYnXdMYL3Mhh6ieMpJ/CB4q8FCFA+KQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iHPWtuco9hfXe0fVC/1ekAvtpP2xYHzUjS2ZxnqKjcu2hplqaZ5NhoPqR5B8htUoR XOQBnSOLrUmIqPYFNSEUzYzoRrqoWQmd/ThOnkzYZ4lgbqLTmU3z8S+Mu3uhikttps 0ELTmwxQnJjwmXGrLKhlLoSnPMfNBfY3aFQqeZgMbIUn41UooHaKY1NxLUMvYRzqEa EGN6EmM/C4SqdN1LFsb01bmf3jEoCb0Sns91bd8BGYKpchxu3ssYf1x5WD/ozV07Si 0fcd5yGAEjton9tt51Bk8/DhsuhMqWCxwOIJ03Ow/D8F+14x9LL5lsl2P1kH1mablp YXnUbnMLxLSrg== From: Eshel Yaron In-Reply-To: <86ldxwsf11.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 06 Nov 2024 14:49:46 +0200") References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <865xp82vd2.fsf@gnu.org> <86ldxwsf11.fsf@gnu.org> X-Hashcash: 1:20:241106:eliz@gnu.org::Agtgcoc9IXcDffDd:A/X X-Hashcash: 1:20:241106:74091@debbugs.gnu.org::lLnUSZC3f45sskNj:8VP4 Date: Wed, 06 Nov 2024 15:12:24 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: 74091@debbugs.gnu.org >> Date: Wed, 06 Nov 2024 09:01:16 +0100 >> >> FYI after spending a bit more time on this issue, I concluded that >> (kill-all-local-variables t) is inherently problematic: it breaks >> assumptions that Emacs relies on. (See bug#73005 for another example.) >> >> It doesn't seem like killing permanent-local variables in the work >> buffers is necessary ATM, so the fix I'm using is the following: > > Can't _any_ variable become permanent-local, by virtue of some Lisp > program or the user giving it a permanent-local property? > > More generally, how do we know that there are no permanent-local > variables out there that affect layout, and thus affect the results of > this function? > > I believe these considerations were those which led the author to use > kill-all-local-variables like this: we want to be sure that nothing > will dupe string-pixel-width into producing unexpected results. Yes, this reasoning is perfectly understandable. However, the current way of killing all permanent-local variables has bad consequences that that author, naturally, did not expect. So my suggestion is to avoid (kill-all-local-variables t) here and elsewhere. For string-pixel-width specifically, we take care to clear variables that may affect width calculation. If other variables may interfere, we should just clear those too. Cheers, Eshel From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2024 11:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eshel Yaron , Stefan Monnier Cc: 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173115084326088 (code B ref 74091); Sat, 09 Nov 2024 11:15:02 +0000 Received: (at 74091) by debbugs.gnu.org; 9 Nov 2024 11:14:03 +0000 Received: from localhost ([127.0.0.1]:53666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9jPn-0006mi-7r for submit@debbugs.gnu.org; Sat, 09 Nov 2024 06:14:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9jPk-0006m4-Lg for 74091@debbugs.gnu.org; Sat, 09 Nov 2024 06:14:01 -0500 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 1t9jPf-0006Ew-0b; Sat, 09 Nov 2024 06:13:55 -0500 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=xoEkT3k3MDa0oGaHoPtmR8/6briKBBub9zx00tPwyXw=; b=QcR17iGhazcy TpbPaQMEckcv9wJhKE8j5Lcoq9v0IKy5GfSxgH+cVQWm1QKBtPikcVMu52EVDrdtEGGDgPUlhdvbF jYPl8CB+d8mQYyB47rGwuQe6f/UzORsARuonI+Ac/e1Zb6tWT0YNQUHAl4DyxAmpAePuIozf4/0T3 RXNkx0BVRsvrqjZB8+ePwnWFbKK45pQ6e1J7HAu/usqz0i8AZ4Fqy2cG8Zs6nvVTmHle/Hcyw5j6K uLzlWoVNfXg82sOzKM7FTHMxeqFYfrDpcKF5OW492TAe1ziWlKLJTrKL40T1OLUd7t5trmNQZ6CyE YmWzms0BFShLkOzV8j0E9w==; Date: Sat, 09 Nov 2024 13:13:52 +0200 Message-Id: <86a5e8mzgv.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Eshel Yaron on Wed, 06 Nov 2024 15:12:24 +0100) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <865xp82vd2.fsf@gnu.org> <86ldxwsf11.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Eshel Yaron > Cc: 74091@debbugs.gnu.org > Date: Wed, 06 Nov 2024 15:12:24 +0100 > > Eli Zaretskii writes: > > >> From: Eshel Yaron > >> Cc: 74091@debbugs.gnu.org > >> Date: Wed, 06 Nov 2024 09:01:16 +0100 > >> > >> FYI after spending a bit more time on this issue, I concluded that > >> (kill-all-local-variables t) is inherently problematic: it breaks > >> assumptions that Emacs relies on. (See bug#73005 for another example.) > >> > >> It doesn't seem like killing permanent-local variables in the work > >> buffers is necessary ATM, so the fix I'm using is the following: > > > > Can't _any_ variable become permanent-local, by virtue of some Lisp > > program or the user giving it a permanent-local property? > > > > More generally, how do we know that there are no permanent-local > > variables out there that affect layout, and thus affect the results of > > this function? > > > > I believe these considerations were those which led the author to use > > kill-all-local-variables like this: we want to be sure that nothing > > will dupe string-pixel-width into producing unexpected results. > > Yes, this reasoning is perfectly understandable. However, the current > way of killing all permanent-local variables has bad consequences that > that author, naturally, did not expect. So my suggestion is to avoid > (kill-all-local-variables t) here and elsewhere. > > For string-pixel-width specifically, we take care to clear variables > that may affect width calculation. If other variables may interfere, we > should just clear those too. Let's see what Stefan (CC'ed) thinks about these issues. From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2024 16:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Eshel Yaron , 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173116961914224 (code B ref 74091); Sat, 09 Nov 2024 16:27:01 +0000 Received: (at 74091) by debbugs.gnu.org; 9 Nov 2024 16:26:59 +0000 Received: from localhost ([127.0.0.1]:54184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9oId-0003hL-5J for submit@debbugs.gnu.org; Sat, 09 Nov 2024 11:26:59 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9oIa-0003h6-Gh for 74091@debbugs.gnu.org; Sat, 09 Nov 2024 11:26:57 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F3DFC440BFA; Sat, 9 Nov 2024 11:26:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731169609; bh=cQzudkLAGkqSHJxSt9o0lyvvULUxlhKDjCyUSHvqZEg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dotLessx+8xEv41Xgn6TxcWG6DoST3uCiSWKsqO+O+cNej6S+zvE+HMnvVnbM8dmi dAUxAFsHXd7HfSDjTbo+iBSVqCp3efJvepIXM6yTHDispMIDKtXsBASq6/MlNDaW7J PCDS4etZ+/XeyYNbxx3fI3V/Kj2cWZJRsdrfqHRrBcLzQEwaHKdE6BI7oDR40VklK4 eeI/fUj/3/V6D5e6hCjMCb6HIg9oejjudS8W9llJhserofjYm4rKRKHgQOyrj2Ol6K lAfzzeT8psimkq2nhOG2Cei5cCT59LNVRMEhym+dK8b5hQu33I3Um8MiBGxCayvmvi XVsecK2EzAIeQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C7533440B97; Sat, 9 Nov 2024 11:26:49 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 97FE11202FD; Sat, 9 Nov 2024 11:26:49 -0500 (EST) From: Stefan Monnier In-Reply-To: <86ed3w33g1.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 31 Oct 2024 13:41:02 +0200") Message-ID: References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> Date: Sat, 09 Nov 2024 11:26:48 -0500 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.042 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Killing local variables makes the global value of deactivate-mark be > in effect when the command loop decides whether to deactivate the > region after a command finishes. The thing I don't understand is this: Why is the global value of `deactivate-mark` non-nil? After all, since it is buffer-local when set, it should only be non-nil buffer-locally, so the `kill-all-local-variables` should just through away the non-nil setting, whereas it seems that somehow the non-nil setting gets "promoted" to global. I suspect the problem might be a bug in `reset_buffer_local_variables` around: /* Reset all (or most) per-buffer variables to their defaults. */ if (permanent_too) bset_local_var_alist (b, Qnil); I suspect this was OK in the "original" uses of `permanent_too` because "by construction" none of those vars could be "swapped in" (i.e. have their value held in a C variable like `Vdeactivate_mark`), but we now have cases where this is not the case any more, so that if the value of `Vdeactivate_mark` held a buffer-local value, it ends up "promoted" to global. Stefan From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2024 16:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173117028216180 (code B ref 74091); Sat, 09 Nov 2024 16:38:02 +0000 Received: (at 74091) by debbugs.gnu.org; 9 Nov 2024 16:38:02 +0000 Received: from localhost ([127.0.0.1]:54232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9oTJ-0004Cp-ED for submit@debbugs.gnu.org; Sat, 09 Nov 2024 11:38:01 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9oTH-0004CW-4K for 74091@debbugs.gnu.org; Sat, 09 Nov 2024 11:38:00 -0500 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 1t9oTA-0000QZ-L3; Sat, 09 Nov 2024 11:37:52 -0500 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=ZdlGtGA0SGYg/i5RjITmRlXPyMGbuRTd6A39H0J9J1g=; b=BcEs6ETHTl+L +9VTDm650Xweb7oVMmzWPVTND0wLjjuP3qWVGdNIvFaVO+i+4002WASm8J52vnt7oBbuXR4V/qvh7 Z0Do37zYwuxKAQSLJ9ULNJnUcrcUXh6BcrdSW7uZQUNlOaXOXz97KgIt0sJfQMcl3YL31T1da2xr/ tuplq4KXgVlhhpF34HdhvSFNWLnqxUnIepcd/kViQIiaJogQmEV9sSFa6b41lq6Fjddkc3gYIMsgh jS3UoJnjj4vd3hSZotouTDvtM4NidQg4eYe2sEPEekFNedQt0wRAklCkd9N36QOGwIYSIh3ZTXLGC u7rui9LrhsiHlQof6h3NTQ==; Date: Sat, 09 Nov 2024 18:37:49 +0200 Message-Id: <8634k0mkgy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sat, 09 Nov 2024 11:26:48 -0500) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: Eshel Yaron , 74091@debbugs.gnu.org > Date: Sat, 09 Nov 2024 11:26:48 -0500 > > I suspect the problem might be a bug in `reset_buffer_local_variables` around: > > /* Reset all (or most) per-buffer variables to their defaults. */ > if (permanent_too) > bset_local_var_alist (b, Qnil); > > I suspect this was OK in the "original" uses of `permanent_too` because > "by construction" none of those vars could be "swapped in" (i.e. have > their value held in a C variable like `Vdeactivate_mark`), but we now > have cases where this is not the case any more, so that if the value of > `Vdeactivate_mark` held a buffer-local value, it ends up "promoted" > to global. Which development in Emacs made such a "promotion" possible? From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2024 18:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173117558531792 (code B ref 74091); Sat, 09 Nov 2024 18:07:02 +0000 Received: (at 74091) by debbugs.gnu.org; 9 Nov 2024 18:06:25 +0000 Received: from localhost ([127.0.0.1]:54406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9pqq-0008Gh-UN for submit@debbugs.gnu.org; Sat, 09 Nov 2024 13:06:25 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38549) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9pqn-0008GS-7b for 74091@debbugs.gnu.org; Sat, 09 Nov 2024 13:06:23 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 11B6180B3A; Sat, 9 Nov 2024 13:06:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731175574; bh=uzoKMaNAt2fpsYsmqKl+pvbIqPHJOkHBiuAuo/0manU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=I76sxKKeesWRavSyKeQGTNU90xmttXgPoBlLs3v2dGe087XuXAhfplI/ZnS0EDU3n 2H3zNGP63jOOnq0We1l8voeqXpsuR7o7DsuuqOHSN7t//yZ90IMrRun2Iop2VfLkH7 SdI9BLQ8n9cKY7+SToDO/uJvJonr2Di5UlT/00d9i+Y3QWTnYjvX2c1ELP6owHI91q Ur+9eijXxhPBDtEffKc4/JgH8d4SctC6wXBZFYZFSgD8Uqi3PIHWAftG3AxyxIvQHT /JdbWq30TN1aoF9VQqUv+6ZX9xidBrkLd1ogB/1+c9okW6z4KdQgPgtlO1QW21YrtJ 7G6EEZIp4N6eg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 01F13801F1; Sat, 9 Nov 2024 13:06:14 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C3A4E12056B; Sat, 9 Nov 2024 13:06:13 -0500 (EST) From: Stefan Monnier In-Reply-To: <8634k0mkgy.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Nov 2024 18:37:49 +0200") Message-ID: References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> Date: Sat, 09 Nov 2024 13:06:13 -0500 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.040 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I suspect the problem might be a bug in `reset_buffer_local_variables` around: >> >> /* Reset all (or most) per-buffer variables to their defaults. */ >> if (permanent_too) >> bset_local_var_alist (b, Qnil); >> >> I suspect this was OK in the "original" uses of `permanent_too` because >> "by construction" none of those vars could be "swapped in" (i.e. have >> their value held in a C variable like `Vdeactivate_mark`), but we now >> have cases where this is not the case any more, so that if the value of >> `Vdeactivate_mark` held a buffer-local value, it ends up "promoted" >> to global. Hmm... I was wrong, it's not actually promoted to global, it's just that the former local value "lingers". > Which development in Emacs made such a "promotion" possible? AFAICT the problem is new with the addition of the `kill-permanent` arg to `kill-all-local-variables`. Here's an example of a problem: src/emacs -Q --batch --eval '(message "%s" (list (setq-default foo nil) (setq-local foo t) (kill-all-local-variables t) (local-variable-p `foo) foo (default-value `foo) (with-temp-buffer foo) foo))' => (nil t nil t t nil nil nil) If we call `kill-all-local-variables` without the additional argument, we get the correct answer: (nil t nil nil nil nil nil nil) - Stefan From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2024 18:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.1731176098475 (code B ref 74091); Sat, 09 Nov 2024 18:15:01 +0000 Received: (at 74091) by debbugs.gnu.org; 9 Nov 2024 18:14:58 +0000 Received: from localhost ([127.0.0.1]:54416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9pz8-00007b-14 for submit@debbugs.gnu.org; Sat, 09 Nov 2024 13:14:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9pz6-00007O-Cd for 74091@debbugs.gnu.org; Sat, 09 Nov 2024 13:14:57 -0500 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 1t9pyx-0001YI-Uq; Sat, 09 Nov 2024 13:14:48 -0500 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=ksVAocomiAnwly2KV2GyiBaOaTyzX0zmITrmgB6aVGc=; b=GXb9yY77lEHg migzPBFFnsn0sepMPvonvYrJWvIICBYvANxwU0J5VZe8JKOim/0iMHFzcjMAEwgS6Xhs9qtLq2BKH dc8il4d4OjlUZwi9zTQbeMTqJs5tw8OrhS11WSIZcWj1Qht8w6Y2rAp8nwAD3vgHjnSMyZa2Vx70Z QKE9Ylb6xXKNFXk0nMkUA4yhXhBZD0wW1iemHHK3dAC4FREWzrqaOQVKW2i7aR0cDaZQj/oQ5+F0C O5rVLATENG5OO+XJpPgrDa4z+jqDbiFvTRrL2qRZaHkauBgQr460RI3jHcCOjKoAxbcyTiygt1JBz Nh5p6whExJySgBxjkZhLBQ==; Date: Sat, 09 Nov 2024 20:14:43 +0200 Message-Id: <86ttcgl1f0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sat, 09 Nov 2024 13:06:13 -0500) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: me@eshelyaron.com, 74091@debbugs.gnu.org > Date: Sat, 09 Nov 2024 13:06:13 -0500 > > AFAICT the problem is new with the addition of the `kill-permanent` > arg to `kill-all-local-variables`. > > Here's an example of a problem: > > src/emacs -Q --batch --eval '(message "%s" (list (setq-default foo nil) (setq-local foo t) (kill-all-local-variables t) (local-variable-p `foo) foo (default-value `foo) (with-temp-buffer foo) foo))' > > => > > (nil t nil t t nil nil nil) > > If we call `kill-all-local-variables` without the additional argument, we > get the correct answer: > > (nil t nil nil nil nil nil nil) This feature was introduced in Emacs 29, so we should preferably fix it in Emacs 30. Any suggestions? From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2024 18:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: monnier@iro.umontreal.ca Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.17311773544447 (code B ref 74091); Sat, 09 Nov 2024 18:36:02 +0000 Received: (at 74091) by debbugs.gnu.org; 9 Nov 2024 18:35:54 +0000 Received: from localhost ([127.0.0.1]:54449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9qJN-00019f-Nv for submit@debbugs.gnu.org; Sat, 09 Nov 2024 13:35:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41064) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9qJK-00019M-1m for 74091@debbugs.gnu.org; Sat, 09 Nov 2024 13:35:52 -0500 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 1t9qJD-00044H-RH; Sat, 09 Nov 2024 13:35:43 -0500 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=vey6dHJQZ65dFEZEDz0Wx+mZWEBEeI1tz+yPxgONxyA=; b=HKEqQ66HMFVM Nj5sth1yQbn8TY0lmtN8Hi0kWrhi8sukP2b0N5ztaXqR13bu+Uot4m51I7e8e21AbD+SsxTBMY5Kh BTtu70mLEvRQ8JWw06Dvrhc1Y90o8jHSsO0XXI9FuoQ6SPWaXdDQDPi5pKB6Nd6YguisbR6bAkrk1 dkyf97dlrmRjq3UlBtCjO+8AREs+8RomyjYwdeTD9G+rLzI1/eVZXIpn2QwyoMlIR/6BxP9SoXSKA JlPohivru0wmB9H1G3fGjVFklTBWvQIoHUGJ2uIgbwF4fabjm15oqH9BYTA+buNwJmjf5xWl69u9X G4WM4ewY7V+rvwaBHW3XwA==; Date: Sat, 09 Nov 2024 20:35:40 +0200 Message-Id: <86ses0l0g3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86ttcgl1f0.fsf@gnu.org> (message from Eli Zaretskii on Sat, 09 Nov 2024 20:14:43 +0200) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: me@eshelyaron.com, 74091@debbugs.gnu.org > Date: Sat, 09 Nov 2024 20:14:43 +0200 > From: Eli Zaretskii > > > From: Stefan Monnier > > Cc: me@eshelyaron.com, 74091@debbugs.gnu.org > > Date: Sat, 09 Nov 2024 13:06:13 -0500 > > > > AFAICT the problem is new with the addition of the `kill-permanent` > > arg to `kill-all-local-variables`. > > > > Here's an example of a problem: > > > > src/emacs -Q --batch --eval '(message "%s" (list (setq-default foo nil) (setq-local foo t) (kill-all-local-variables t) (local-variable-p `foo) foo (default-value `foo) (with-temp-buffer foo) foo))' > > > > => > > > > (nil t nil t t nil nil nil) > > > > If we call `kill-all-local-variables` without the additional argument, we > > get the correct answer: > > > > (nil t nil nil nil nil nil nil) > > This feature was introduced in Emacs 29, so we should preferably fix > it in Emacs 30. Any suggestions? I think calling reset_buffer_local_variables with 2nd arg non-zero is not TRT to implement this new argument of kill-all-local-variables, because it does this: /* Reset all (or most) per-buffer variables to their defaults. */ if (permanent_too) bset_local_var_alist (b, Qnil); I think we should instead ignore the permanent-local property of variables. How about the patch below? diff --git a/src/buffer.c b/src/buffer.c index 744b0ef..9e93e0f 100644 --- a/src/buffer.c +++ b/src/buffer.c @@ -113,7 +113,7 @@ #define OVERLAY_COUNT_MAX \ static void call_overlay_mod_hooks (Lisp_Object list, Lisp_Object overlay, bool after, Lisp_Object arg1, Lisp_Object arg2, Lisp_Object arg3); -static void reset_buffer_local_variables (struct buffer *, bool); +static void reset_buffer_local_variables (struct buffer *, int); /* Alist of all buffer names vs the buffers. This used to be a Lisp-visible variable, but is no longer, to prevent lossage @@ -1112,10 +1112,11 @@ reset_buffer (register struct buffer *b) Instead, use Fkill_all_local_variables. If PERMANENT_TOO, reset permanent buffer-local variables. - If not, preserve those. */ + If not, preserve those. PERMANENT_TOO = 2 means ignore + the permanent-local property of non-builtin variables. */ static void -reset_buffer_local_variables (struct buffer *b, bool permanent_too) +reset_buffer_local_variables (struct buffer *b, int permanent_too) { int offset, i; @@ -1141,7 +1142,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too) bset_invisibility_spec (b, Qt); /* Reset all (or most) per-buffer variables to their defaults. */ - if (permanent_too) + if (permanent_too == 1) bset_local_var_alist (b, Qnil); else { @@ -1170,7 +1171,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too) swap_in_global_binding (XSYMBOL (sym)); } - if (!NILP (prop)) + if (!NILP (prop) && permanent_too) { /* If permanent-local, keep it. */ last = tmp; @@ -3001,7 +3002,7 @@ DEFUN ("kill-all-local-variables", Fkill_all_local_variables, /* Actually eliminate all local bindings of this buffer. */ - reset_buffer_local_variables (current_buffer, !NILP (kill_permanent)); + reset_buffer_local_variables (current_buffer, !NILP (kill_permanent) ? 2 : 0); /* Force mode-line redisplay. Useful here because all major mode commands call this function. */ From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Nov 2024 22:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.17311902918761 (code B ref 74091); Sat, 09 Nov 2024 22:12:02 +0000 Received: (at 74091) by debbugs.gnu.org; 9 Nov 2024 22:11:31 +0000 Received: from localhost ([127.0.0.1]:54732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9tg2-0002HF-Ka for submit@debbugs.gnu.org; Sat, 09 Nov 2024 17:11:30 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32137) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t9tg0-0002Gz-C1 for 74091@debbugs.gnu.org; Sat, 09 Nov 2024 17:11:29 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B282644105A; Sat, 9 Nov 2024 17:11:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731190280; bh=k/lZRQ2G98fzgNchZ7/tTEWWuaXfgBL1fFe8EyClXvI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F9whLXoaEerZt0pfdUC9OqVQmtFKq0i3y03MzhQ9JFGJtqaynwSTLirS2G2onoKQw KHQtVjA4/yFbnbwYLs/L5Q2B+w8CTtG+UtHAbgUiVPh+CnmC2VUMQ3fup+de+2O5Fe 1qvxcUe1uKH25vZHYih56UTbUnReNi76nkk2hVepF1khAPH5jFiTJtwZTMkStEYJwa lNIoHr49N6N7u1v9qqnniUSLZ3OPMvBSD5W3jOORMH68k7K80mUMC97d9CfOSf1UFT dwk64Hl5hECt1fRfG5P9QyQHNkELWktkyzXGILcWv6h89eMCuYVevdXGPIi+lxRt3r mHKjm5yS70v0g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CDFC844067F; Sat, 9 Nov 2024 17:11:20 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A2426120352; Sat, 9 Nov 2024 17:11:20 -0500 (EST) From: Stefan Monnier In-Reply-To: <86ses0l0g3.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Nov 2024 20:35:40 +0200") Message-ID: References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> <86ses0l0g3.fsf@gnu.org> Date: Sat, 09 Nov 2024 17:11:19 -0500 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.041 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I think we should instead ignore the permanent-local property of > variables. How about the patch below? Funny: I went through 3 different versions of a patch and ended up with basically the same patch as yours. > @@ -1170,7 +1171,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too) > swap_in_global_binding (XSYMBOL (sym)); > } > > - if (!NILP (prop)) > + if (!NILP (prop) && permanent_too) > { > /* If permanent-local, keep it. */ > last = tmp; This should be an || rather than an &&, no? Stefan From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Nov 2024 05:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173121785823307 (code B ref 74091); Sun, 10 Nov 2024 05:51:01 +0000 Received: (at 74091) by debbugs.gnu.org; 10 Nov 2024 05:50:58 +0000 Received: from localhost ([127.0.0.1]:55272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tA0qg-00063r-Ha for submit@debbugs.gnu.org; Sun, 10 Nov 2024 00:50:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tA0qe-00063d-6o for 74091@debbugs.gnu.org; Sun, 10 Nov 2024 00:50:57 -0500 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 1tA0qY-0005Qp-Gf; Sun, 10 Nov 2024 00:50:50 -0500 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=HEeP/q+3wkxiIAOPqvuTbucsHMVEVDRT70L/Bsw4QgY=; b=ISMT11JEmmKy Ua8YjrDc6ljIy5pVrQ0Nx6nV+O1gPMUEybCQ6z1fkOfdgwaAVO7UX17voHfTBkhb7JQB5rGY19DWG WeyS1cJSIcMGtx4QJucOwnf7V80ofEAriX9FCZVnYxHpOXGoTXRYJ+0h8yaSjwXHfJQhYoh1sPpPJ UmvdwaybAC4ORc1nS27GWP+K6f63UMoRCRkpOyVKWYuuYZQfJUtz3V11xBPYO6I7QzAgbxz5Yi9+L K+YaniTGxK1199koGQ0HVnTrHXplMw04VsQjcOWGP4ZnkEPm0xeEFQ1fhSm97xTKL8C2CatwPNlCG BuiWWZ+Vj+nDk59RJfeTPg==; Date: Sun, 10 Nov 2024 07:50:47 +0200 Message-Id: <86o72nljrc.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sat, 09 Nov 2024 17:11:19 -0500) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> <86ses0l0g3.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: me@eshelyaron.com, 74091@debbugs.gnu.org > Date: Sat, 09 Nov 2024 17:11:19 -0500 > > > I think we should instead ignore the permanent-local property of > > variables. How about the patch below? > > Funny: I went through 3 different versions of a patch and ended up with > basically the same patch as yours. ;-) > > @@ -1170,7 +1171,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too) > > swap_in_global_binding (XSYMBOL (sym)); > > } > > > > - if (!NILP (prop)) > > + if (!NILP (prop) && permanent_too) > > { > > /* If permanent-local, keep it. */ > > last = tmp; > > This should be an || rather than an &&, no? No, I don't think so. If the permanent-local property is nil, we should not take this branch, even if permanent_too is non-zero. Or what am I missing? From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Nov 2024 06:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: monnier@iro.umontreal.ca Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.17312214622535 (code B ref 74091); Sun, 10 Nov 2024 06:52:02 +0000 Received: (at 74091) by debbugs.gnu.org; 10 Nov 2024 06:51:02 +0000 Received: from localhost ([127.0.0.1]:55370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tA1mn-0000eX-UL for submit@debbugs.gnu.org; Sun, 10 Nov 2024 01:51:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tA1ml-0000U1-Gd for 74091@debbugs.gnu.org; Sun, 10 Nov 2024 01:51:00 -0500 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 1tA1mf-0003lU-5z; Sun, 10 Nov 2024 01:50:53 -0500 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=pwhhX54tvLE/IdE6w8nz/DXhWoTyYIZGxXKO5QFtdz0=; b=bb0agavKpF+s n+Lg0ALHsXk6R10SG40Bq6DXjkiBolG4tkPwd7fWioQczPIWWdcKIRWnMPBiSJBs7T9PRznZdSPQT srxV3R1c7F2/CPkP5EMVFymnopK66gSSgq29IrERL1ERc4q3lUfAxIQnRPyURrOsJaxa9ub3/uGC0 k9W7YX+ss76uhfZEFjTfs5NjNIJm3WXtruPFmZm3uCldzmXNs3KdrCgcHS5zh+q/5Do+/PsrsICiQ mfjLZi79jPKr0rQcv0G3sBNlowME1uxkGZ4lzGoH9aClYCHK430y09M6So9tGh0SqJ4euX/ey7G0P dfNRsg62mwqSLHW4zqKLgA==; Date: Sun, 10 Nov 2024 08:50:49 +0200 Message-Id: <86jzdblgza.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86o72nljrc.fsf@gnu.org> (message from Eli Zaretskii on Sun, 10 Nov 2024 07:50:47 +0200) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> <86ses0l0g3.fsf@gnu.org> <86o72nljrc.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: me@eshelyaron.com, 74091@debbugs.gnu.org > Date: Sun, 10 Nov 2024 07:50:47 +0200 > From: Eli Zaretskii > > > > @@ -1170,7 +1171,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too) > > > swap_in_global_binding (XSYMBOL (sym)); > > > } > > > > > > - if (!NILP (prop)) > > > + if (!NILP (prop) && permanent_too) > > > { > > > /* If permanent-local, keep it. */ > > > last = tmp; > > > > This should be an || rather than an &&, no? > > No, I don't think so. If the permanent-local property is nil, we > should not take this branch, even if permanent_too is non-zero. Or > what am I missing? Hmm... but something is still amiss, because Emacs built with my patch comes up without fontifications, although font-lock-mode is t. Any ideas? From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Nov 2024 10:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: monnier@iro.umontreal.ca Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173123539411264 (code B ref 74091); Sun, 10 Nov 2024 10:44:02 +0000 Received: (at 74091) by debbugs.gnu.org; 10 Nov 2024 10:43:14 +0000 Received: from localhost ([127.0.0.1]:55860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tA5PV-0002vc-Kz for submit@debbugs.gnu.org; Sun, 10 Nov 2024 05:43:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tA5PT-0002vI-Ii for 74091@debbugs.gnu.org; Sun, 10 Nov 2024 05:43:12 -0500 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 1tA5PO-0001VZ-47; Sun, 10 Nov 2024 05:43:06 -0500 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=B+XmVS9+PwLL/0SthJsP7vS93EiDQ2Zavdt/I19bs/c=; b=Wd5ZqkDQNzMa mgbI02L4eWn9vN4AoIWSnBB1KPdkrFEE1QZ5rCvZCWKYiDl0RprhWj8ZfPKVo0GCUSEKbXboOieKn GP5feEX2FPuYVah1wNUxvWKdJ6P7AdeRSrRhqZC6AhZNOHfmhVDp6Ce9YS2ZVpzzXyQGsYoLFuHqo ixv/GsF+I1hUEm7ZmsFTB/xnG3/zdqyufR27VSnDlICYtcG67aSWT5rDOecF2wg1zhjTaF5nAKJKP VXAsB4QigaiRDma+N7fv64XFBks78JFG2W5Ti4SHPpuRkhMnHGfvwpfj4KU6LyhgiwGkDvyGL8Akc OdjhpSXueOErxc/Pdr6Z6w==; Date: Sun, 10 Nov 2024 12:42:59 +0200 Message-Id: <86frnzl68c.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86jzdblgza.fsf@gnu.org> (message from Eli Zaretskii on Sun, 10 Nov 2024 08:50:49 +0200) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> <86ses0l0g3.fsf@gnu.org> <86o72nljrc.fsf@gnu.org> <86jzdblgza.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: me@eshelyaron.com, 74091@debbugs.gnu.org > Date: Sun, 10 Nov 2024 08:50:49 +0200 > From: Eli Zaretskii > > > Cc: me@eshelyaron.com, 74091@debbugs.gnu.org > > Date: Sun, 10 Nov 2024 07:50:47 +0200 > > From: Eli Zaretskii > > > > > > @@ -1170,7 +1171,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too) > > > > swap_in_global_binding (XSYMBOL (sym)); > > > > } > > > > > > > > - if (!NILP (prop)) > > > > + if (!NILP (prop) && permanent_too) > > > > { > > > > /* If permanent-local, keep it. */ > > > > last = tmp; > > > > > > This should be an || rather than an &&, no? > > > > No, I don't think so. If the permanent-local property is nil, we > > should not take this branch, even if permanent_too is non-zero. Or > > what am I missing? > > Hmm... but something is still amiss, because Emacs built with my patch > comes up without fontifications, although font-lock-mode is t. Any > ideas? Sorry, here's the correct patch: diff --git a/src/buffer.c b/src/buffer.c index 744b0ef..995984e 100644 --- a/src/buffer.c +++ b/src/buffer.c @@ -113,7 +113,7 @@ #define OVERLAY_COUNT_MAX \ static void call_overlay_mod_hooks (Lisp_Object list, Lisp_Object overlay, bool after, Lisp_Object arg1, Lisp_Object arg2, Lisp_Object arg3); -static void reset_buffer_local_variables (struct buffer *, bool); +static void reset_buffer_local_variables (struct buffer *, int); /* Alist of all buffer names vs the buffers. This used to be a Lisp-visible variable, but is no longer, to prevent lossage @@ -1112,10 +1112,11 @@ reset_buffer (register struct buffer *b) Instead, use Fkill_all_local_variables. If PERMANENT_TOO, reset permanent buffer-local variables. - If not, preserve those. */ + If not, preserve those. PERMANENT_TOO = 2 means ignore + the permanent-local property of non-builtin variables. */ static void -reset_buffer_local_variables (struct buffer *b, bool permanent_too) +reset_buffer_local_variables (struct buffer *b, int permanent_too) { int offset, i; @@ -1141,7 +1142,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too) bset_invisibility_spec (b, Qt); /* Reset all (or most) per-buffer variables to their defaults. */ - if (permanent_too) + if (permanent_too == 1) bset_local_var_alist (b, Qnil); else { @@ -1170,7 +1171,7 @@ reset_buffer_local_variables (struct buffer *b, bool permanent_too) swap_in_global_binding (XSYMBOL (sym)); } - if (!NILP (prop)) + if (!NILP (prop) && !permanent_too) { /* If permanent-local, keep it. */ last = tmp; @@ -3001,7 +3002,7 @@ DEFUN ("kill-all-local-variables", Fkill_all_local_variables, /* Actually eliminate all local bindings of this buffer. */ - reset_buffer_local_variables (current_buffer, !NILP (kill_permanent)); + reset_buffer_local_variables (current_buffer, !NILP (kill_permanent) ? 2 : 0); /* Force mode-line redisplay. Useful here because all major mode commands call this function. */ From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Nov 2024 16:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.17312572178920 (code B ref 74091); Sun, 10 Nov 2024 16:47:02 +0000 Received: (at 74091) by debbugs.gnu.org; 10 Nov 2024 16:46:57 +0000 Received: from localhost ([127.0.0.1]:56414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAB5V-0002Jo-Fx for submit@debbugs.gnu.org; Sun, 10 Nov 2024 11:46:57 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAB5T-0002Jc-SC for 74091@debbugs.gnu.org; Sun, 10 Nov 2024 11:46:56 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 821D31001D9; Sun, 10 Nov 2024 11:46:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731257209; bh=cR5dzDYgpLR3ODNAln2RJTnPhrtc7COtQFsEjFpWl0w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ee+OJFtEW2xpFBYP0Jzabe+BPtdZV6LPatZILJiin8O2mvzWD24VNy+LAJYqE853e dXZ4MEKVFL4jy5LaF9kDHfNq3dmkfaS7MtJeDBHgNWocMVziiyrWvzWiokutLMhGBW ZRUs9AloNI7c1tQmkiwJTTwCqa1LASFGjuZMftH/Pau1H8O6kiP+ZCKULiL7nXF4br WRYL4h1tzoFrHHeZPE0Rp2Nsf8pKd44RQhhPZakQgmCEYWUMcO1SuYGjVbro0Du2H2 iBCrlXPWX3fHB0lMhgCXxbvGMJWmTzHtZZ/+HWf7U3JlHABEzDeVIXVz6YMzEtbFF4 vx9M6J9Zpgx3g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BEFFB100180; Sun, 10 Nov 2024 11:46:49 -0500 (EST) Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 812F5120401; Sun, 10 Nov 2024 11:46:49 -0500 (EST) From: Stefan Monnier In-Reply-To: <86frnzl68c.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 10 Nov 2024 12:42:59 +0200") Message-ID: References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> <86ses0l0g3.fsf@gnu.org> <86o72nljrc.fsf@gnu.org> <86jzdblgza.fsf@gnu.org> <86frnzl68c.fsf@gnu.org> Date: Sun, 10 Nov 2024 11:46:47 -0500 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.066 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Sorry, here's the correct patch: Oh, right, I had !(...||...) Thanks, LGTM! Stefan From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Nov 2024 19:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: me@eshelyaron.com, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.17312663832833 (code B ref 74091); Sun, 10 Nov 2024 19:20:01 +0000 Received: (at 74091) by debbugs.gnu.org; 10 Nov 2024 19:19:43 +0000 Received: from localhost ([127.0.0.1]:56652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tADTK-0000jd-Nz for submit@debbugs.gnu.org; Sun, 10 Nov 2024 14:19:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tADTH-0000jN-12 for 74091@debbugs.gnu.org; Sun, 10 Nov 2024 14:19:40 -0500 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 1tADR4-0002zn-4Q; Sun, 10 Nov 2024 14:17:22 -0500 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=QeBmsFFn3JgZuXneu4MSHjsK6CkqjqPDA51BsRjheCY=; b=pCLIr13BYgf6 G9WAoMdsyZQW4qb420zqwo4d3SunQDK9PLbwuck9MUeTWeIz61TOhHsOy6NPnTDrWgyaf6NLglBmQ aB7qUv/3B0LtXJPsa9mlw/4MMHVkRTW8sCT/lqytsc++TAgEkqazX398ku+4jErqIxlGg2RYUkJwR uKxXesE8kC2kAVrFywsP4AD8w0N4lFN0VwKiqFcM0Le/usoPX6hRXKRNGPsLw38NZoGevRqKNHB6d dSRSgwNueXDoo+hnOsJhzrIDtFiBNCRY6j1f6YC4F1WTU3Ov9ef47w7dRddeoMESwti3DbBAYiZCK tZdxU1Fo6WSYswk3Tr+gTg==; Date: Sun, 10 Nov 2024 21:17:19 +0200 Message-Id: <868qtqlwzk.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sun, 10 Nov 2024 11:46:47 -0500) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> <86ses0l0g3.fsf@gnu.org> <86o72nljrc.fsf@gnu.org> <86jzdblgza.fsf@gnu.org> <86frnzl68c.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: me@eshelyaron.com, 74091@debbugs.gnu.org > Date: Sun, 10 Nov 2024 11:46:47 -0500 > > > Sorry, here's the correct patch: > > Oh, right, I had !(...||...) > Thanks, LGTM! Thanks, installed on the emacs-30 branch. From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Nov 2024 20:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Stefan Monnier , 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173127000714106 (code B ref 74091); Sun, 10 Nov 2024 20:21:02 +0000 Received: (at 74091) by debbugs.gnu.org; 10 Nov 2024 20:20:07 +0000 Received: from localhost ([127.0.0.1]:56722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAEPm-0003fC-TA for submit@debbugs.gnu.org; Sun, 10 Nov 2024 15:20:07 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:53468 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAEPi-0003d1-8c for 74091@debbugs.gnu.org; Sun, 10 Nov 2024 15:20:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1731270001; bh=NmueccbTKXDaX7SiBSwCS8enf+aFZatDvF1Sd2pVq4I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KQsLnrCiq4QKC/eKWbAWzgpa62UZYB9yng3O+HbgQ9jdGH1WaWI8UmMwTj56fzQX+ asS95ucd9r5FFpbhbZJsk19NmpxcX+523t99S9WayqDYxfag+7X1/X+BidUUSQbhKc fCkUQl9mcq59in+1SRIuT5MwFKSfisrTU6OjqLvydtI7SCwqnw1IUGvOF4aMaRTzBq szMr0AEwuQbQS6l4Ms9k10itRHqlAgKjjIkJl12ZytaSy9QWPHYCo//5qPp4kxskLG t55Pn5lwPl6k9QGnwKAd8hwqigXfq6aQOqvJa7iJf+dzVfQdCkh8B+DKVoyOl+PJGA +hPfGpmO+WrAQ== From: Eshel Yaron In-Reply-To: <868qtqlwzk.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 10 Nov 2024 21:17:19 +0200") References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> <86ses0l0g3.fsf@gnu.org> <86o72nljrc.fsf@gnu.org> <86jzdblgza.fsf@gnu.org> <86frnzl68c.fsf@gnu.org> <868qtqlwzk.fsf@gnu.org> Date: Sun, 10 Nov 2024 21:19:58 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Stefan Monnier >> Cc: me@eshelyaron.com, 74091@debbugs.gnu.org >> Date: Sun, 10 Nov 2024 11:46:47 -0500 >> >> > Sorry, here's the correct patch: >> >> Oh, right, I had !(...||...) >> Thanks, LGTM! > > Thanks, installed on the emacs-30 branch. Thank you both for getting to the bottom of this issue. Note that once this fix lands on master, we should be able to revert 57fe24961fd. Works well for me so far. Best, Eshel From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Nov 2024 03:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eshel Yaron Cc: monnier@iro.umontreal.ca, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173129548621884 (code B ref 74091); Mon, 11 Nov 2024 03:25:01 +0000 Received: (at 74091) by debbugs.gnu.org; 11 Nov 2024 03:24:46 +0000 Received: from localhost ([127.0.0.1]:57341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAL2j-0005gu-Fe for submit@debbugs.gnu.org; Sun, 10 Nov 2024 22:24:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAL2h-0005gf-BT for 74091@debbugs.gnu.org; Sun, 10 Nov 2024 22:24:44 -0500 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 1tAL0V-0006L5-05; Sun, 10 Nov 2024 22:22:27 -0500 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=n3FK3ALBfGd6fUofyw/oCGL830DZMG4VsyRgnEuCGnE=; b=B25sdRuuzyvh MBSmpBkChaF1lWxBHrb4mlqXT7vYQx2RLl+Iztp9wHHMb4yBEE1iB5lGhMiCzvCnfpFxcQtA/4V9Q 9lP/7A+t7LuoADY+YGcHrU8cN3lVkU5GFGJxdGuC5mTx9dYgaDrHiECo6uZHtlltFBGwGcTFyJExV 2JgjH5JII1MChm0KaFazA15rLg9TU0nehpOxQLLApVKg1o3yDXae4Ad752F07hrA+2ycsVLlgtSEG qOFlWqKSfP3DZIPxyVn/usj/1RktgBMd9fd/B0OFW6uhpKpRH3PotJ23MqUORrOvV6JjVfF2YKmuE LBqg6rFhLhpvJVwLt8SYDw==; Date: Mon, 11 Nov 2024 05:22:25 +0200 Message-Id: <8634jylaj2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Eshel Yaron on Sun, 10 Nov 2024 21:19:58 +0100) References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> <86ses0l0g3.fsf@gnu.org> <86o72nljrc.fsf@gnu.org> <86jzdblgza.fsf@gnu.org> <86frnzl68c.fsf@gnu.org> <868qtqlwzk.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Eshel Yaron > Cc: Stefan Monnier , 74091@debbugs.gnu.org > Date: Sun, 10 Nov 2024 21:19:58 +0100 > > Eli Zaretskii writes: > > >> From: Stefan Monnier > >> Cc: me@eshelyaron.com, 74091@debbugs.gnu.org > >> Date: Sun, 10 Nov 2024 11:46:47 -0500 > >> > >> > Sorry, here's the correct patch: > >> > >> Oh, right, I had !(...||...) > >> Thanks, LGTM! > > > > Thanks, installed on the emacs-30 branch. > > Thank you both for getting to the bottom of this issue. Note that once > this fix lands on master, we should be able to revert 57fe24961fd. > Works well for me so far. I see no need to revert that commit, it doesn't cause any problems AFAICT. From unknown Sun Jun 22 00:44:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74091: 31.0.50; string-pixel-width in mode line disables region Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Nov 2024 06:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@iro.umontreal.ca, 74091@debbugs.gnu.org Received: via spool by 74091-submit@debbugs.gnu.org id=B74091.173130795730050 (code B ref 74091); Mon, 11 Nov 2024 06:53:01 +0000 Received: (at 74091) by debbugs.gnu.org; 11 Nov 2024 06:52:37 +0000 Received: from localhost ([127.0.0.1]:57905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAOHs-0007oc-Tc for submit@debbugs.gnu.org; Mon, 11 Nov 2024 01:52:37 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:60816 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAOHr-0007oU-9u for 74091@debbugs.gnu.org; Mon, 11 Nov 2024 01:52:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1731307954; bh=PEMhrcOWnHs70pR+I2QjTrZCyou45QqCiephGYLolJs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=icL0WTQDPg6HsmCzJcoP9apsRWw1HAyJKUCVoXpW01syhZwZ2kaOuZzOnVCMKqkG6 d7gu4CY8toFuKPSQNirq47Tldhc/iw3EvuBuNJI3P4ZqG5Jurq0cmHp+b4XLkMz0sV J5e4VE7C7RH5+isXVUL89w3khY1EsACur4P766mUcUQd0+A1GfA5YqTqB7OYx/fMPm AcE9pDV7BnbBSHpqgBLXaAVHSMNY/1VURPdOtTdssTFoZzx/Gh/Ph+ezF/Q6Ua9KY2 I90WH/Jkr89nCriOaftssS+/KTkeHlSCQaUZiJYXnYSzEFQjO5mBS8efHyk7zdNr3B Cmj/fAfQIcE7Q== From: Eshel Yaron In-Reply-To: <8634jylaj2.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 11 Nov 2024 05:22:25 +0200") References: <86y1254owq.fsf@gnu.org> <86ldy54m2g.fsf@gnu.org> <86ed3w33g1.fsf@gnu.org> <8634k0mkgy.fsf@gnu.org> <86ttcgl1f0.fsf@gnu.org> <86ses0l0g3.fsf@gnu.org> <86o72nljrc.fsf@gnu.org> <86jzdblgza.fsf@gnu.org> <86frnzl68c.fsf@gnu.org> <868qtqlwzk.fsf@gnu.org> <8634jylaj2.fsf@gnu.org> Date: Mon, 11 Nov 2024 07:52:32 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: Stefan Monnier , 74091@debbugs.gnu.org >> Date: Sun, 10 Nov 2024 21:19:58 +0100 >> >> Eli Zaretskii writes: >> >> >> From: Stefan Monnier >> >> Cc: me@eshelyaron.com, 74091@debbugs.gnu.org >> >> Date: Sun, 10 Nov 2024 11:46:47 -0500 >> >> >> >> > Sorry, here's the correct patch: >> >> >> >> Oh, right, I had !(...||...) >> >> Thanks, LGTM! >> > >> > Thanks, installed on the emacs-30 branch. >> >> Thank you both for getting to the bottom of this issue. Note that once >> this fix lands on master, we should be able to revert 57fe24961fd. >> Works well for me so far. > > I see no need to revert that commit, it doesn't cause any problems > AFAICT. The potential problem is misleading or confusing folks reading this code in the future, since it implies (quite explicitly with the comments) that there's a need to bind deactivate-mark, where in fact there isn't. But OK, it's a small concern, so if you find it harmless I won't insist. Eshel