Received: (at 79927) by debbugs.gnu.org; 4 Dec 2025 12:29:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 04 07:29:02 2025
Received: from localhost ([127.0.0.1]:48237 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vR8SD-0005cl-Ps
for submit <at> debbugs.gnu.org; Thu, 04 Dec 2025 07:29:02 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33615)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vR8SC-0005cV-8F
for 79927 <at> debbugs.gnu.org; Thu, 04 Dec 2025 07:29:00 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B7A8781C24;
Thu, 4 Dec 2025 07:28:54 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1764851333;
bh=QjTNjLSgJGVUQrSaSYvaRHH+bL/5pMZ+ZIwEncQuFpI=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=o+yfO1t89SehSPfTkqQYWcOkaN852XkilZBJUqETc+DuA7lyaKWy+b3Yb6bsMe3V9
QATF/7MclAD6ZhOhxVz+89ZDjmuKZRi5UrOyZA5GG92wKMxJRWIjTzBD3oh0akVRHV
FkMZvllE2MOlIBOHtTOI7MFXdubYMHwj8oNnX4rM3SgmW/rLZOkl80duVQPRzlD2IU
ewpA8jxvzWr7MmK/fkMof/LBz8r9/b0bPh7JdrrNhlkIBq8Q8ZWo/HT1CU363H84zJ
yj2RZzpKre54r2oyEbP5Nu477wBLyj1e8A7SU6WS5zrc/MnVoTBqgWl8IAPF5n/+1c
13vgbsugkQfVA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 26726805DE;
Thu, 4 Dec 2025 07:28:53 -0500 (EST)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D984012060B;
Thu, 4 Dec 2025 07:28:51 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Ignacio Casso San =?windows-1252?Q?Rom=E1n?= <ignaciocasso@HIDDEN>
Subject: Re: bug#79927: 29.1; Unexpected buffer point movement on redisplay
In-Reply-To: <SV0P279MB044204AD0E554CC373630EFEC6A6A@HIDDEN>
Message-ID: <jwvv7imcuel.fsf-monnier+emacs@HIDDEN>
References: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN>
<86ms424adq.fsf@HIDDEN>
<SV0P279MB0442252DEC6BCBA711506547C6D8A@HIDDEN>
<86seds3nvx.fsf@HIDDEN>
<SV0P279MB0442CECC796A20B54473A58DC6D8A@HIDDEN>
<jwv7bv3dqg8.fsf-monnier+emacs@HIDDEN>
<SV0P279MB044204AD0E554CC373630EFEC6A6A@HIDDEN>
Date: Thu, 04 Dec 2025 07:28: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.232 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79927
Cc: Eli Zaretskii <eliz@HIDDEN>,
"79927 <at> debbugs.gnu.org" <79927 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Yes I know, but please see the original email for more context on my
> issue, this is just a minimal reproduction example that I wrote
Your original report doesn't show the actual code you used, where the
problem showed up. My comment just points out
(goto-char FOO)
... do BLABLA ...
<presume we're still at FOO>
is a problem if the current buffer is not in the selected window as soon
as BLABLA can do complex enough things like select arbitrary other
windows, redsplay, etc...
If your original code did something like that, then it needs to be fixed
because I think "fixing" it in Emacs is a daunting task.
> Shouldn't we ensure that the semantics with debugging enabled and
> disabled are always consistent?
Of course we should and we try, but sometimes we fail (debugging
process filters is the one where I bump into such failures most often).
For the specific problem of debugging, we should be able to fix it
without too much trouble by saving/restoring more points upon entry/exit
to/from the debugger.
Stefan
bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.
Received: (at 79927) by debbugs.gnu.org; 4 Dec 2025 09:28:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 04 04:28:18 2025
Received: from localhost ([127.0.0.1]:47560 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vR5dJ-0004hD-Ro
for submit <at> debbugs.gnu.org; Thu, 04 Dec 2025 04:28:18 -0500
Received: from mail-norwayeastazolkn19011029.outbound.protection.outlook.com
([52.103.51.29]:12464 helo=OLAP279CU001.outbound.protection.outlook.com)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ignaciocasso@HIDDEN>)
id 1vR5dG-0004gy-Mg
for 79927 <at> debbugs.gnu.org; Thu, 04 Dec 2025 04:28:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=p04yrnjrMS71tfWi0Tfu0WnbBQSzltRy7z7+9dFBQLcggH01zsKKeEs3jTUzvwvOm+PJJ/AuS1FXwbbpnLfe2AgHEdIKKtz/0ZOmz2VhwS9rNG6Z9NWl/p40IlR7lrNbxmwwRMcKwbZwQzCJnF8l0kvqrxz2jvV5z5RomKTZAp3SSLH6mHid+SJWzdTAndaaGWIichCqlUhoSRo5z2ghOfQo3ILoU8LiuB9Lrd7KAtuekooN+V8s13L5uDW76lSzsB/9KI4NgVYP3R5dg6kEofSOf98L4+6voG4x0uhLCSHYD470MPgECWTDE1dKI7VFqq5P11cHZC3svfQiKHaUGA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=+vbR3aKiyO0moyAh2jFKb+5EKQiZIkRPXovKRqyVWlo=;
b=aSBkvm440wjDfdJcwKfb8ynHmtiwHTEt1Z/7tOS89EzH/iOvcZJnRcmR5x7yHJjoVitOF48PmimvwuK0Czw585IFBI4XR5wRzkw5QUCkk7Vqa4sod7QJMSlG4wqaA3xGbks2fbTZxwkjvZhV5CmF/vZx5E7mgZcLGWFcGBgJncHTfoxgjxe72+jrUANL0gQiXHgn55b+ieog0KdST4kv29DfQST77LXTu+ypot0U92eEwSuX5oI2kKACpJNKdn+xesUi9lzlaP5QHe4jHlPnLk9qnqyi6Iwei53fDq2DKgv20INo5wgwBy9Y6eI0b88CZBguRNGheAsVeIN1+x7z7A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=+vbR3aKiyO0moyAh2jFKb+5EKQiZIkRPXovKRqyVWlo=;
b=A2upZ4gZZ4tlNelhFhjqof6d3cnVpwaGGPn34wfwXB2cd5vMz2gr0PlhSxy0v+VJMv631d6Cr5c2a2zUtaUeaH88cj+tnjY/eWz5ijCbZhFd/mxCAspVI6A9q3vuGtcxWa2+rvDh1Vn1cAH9X5ildHFcuiuGZG7l8yzJWxf8zqztHMVR3ro9yQLlgUfco0L0EnBMg7Jkh1Oqj0SWhzXwD1Y/k64Sc24SXzqHqy/QbBcUUECPIKMwOErHwPeFQhwP+Px9OCRHst9TDbMV7QnPkN6YjWLCjoRKvdi1erwwL+mH5Ch80wkbQHQRG21fRxNjnEcfyo02/B0MotFx18RDOA==
Received: from SV0P279MB0442.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:19::11)
by SVZP279MB0757.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:27::5) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9388.11; Thu, 4 Dec
2025 09:28:06 +0000
Received: from SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
([fe80::e7dc:921d:1322:a269]) by SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
([fe80::e7dc:921d:1322:a269%7]) with mapi id 15.20.9388.003; Thu, 4 Dec 2025
09:28:06 +0000
From: =?iso-8859-1?Q?Ignacio_Casso_San_Rom=E1n?= <ignaciocasso@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: RE: bug#79927: 29.1; Unexpected buffer point movement on redisplay
Thread-Topic: bug#79927: 29.1; Unexpected buffer point movement on redisplay
Thread-Index: AQHcYrs/ZfHPjlDt8Uazhj06KM3jFrUMwgERgAFUMSSAAGSn54AADYmzgAIipYCAAI8xkw==
Date: Thu, 4 Dec 2025 09:28:06 +0000
Message-ID: <SV0P279MB044204AD0E554CC373630EFEC6A6A@HIDDEN>
References: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN>
<86ms424adq.fsf@HIDDEN>
<SV0P279MB0442252DEC6BCBA711506547C6D8A@HIDDEN>
<86seds3nvx.fsf@HIDDEN>
<SV0P279MB0442CECC796A20B54473A58DC6D8A@HIDDEN>
<jwv7bv3dqg8.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwv7bv3dqg8.fsf-monnier+emacs@HIDDEN>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SV0P279MB0442:EE_|SVZP279MB0757:EE_
x-ms-office365-filtering-correlation-id: 4aa65a62-783c-4add-d559-08de33176eb8
x-ms-exchange-slblob-mailprops: ScCmN3RHayFlqUYUgmnDb6H2kvF+bMCcaZ23lcoRpoH2eqNs46ypfJv7yaUxoBAn7ONuUkpiY9DCCr91iI/NauYOujzz+jneaVsqz8vwdKSb3TU/aMJrDdjhANK6hVCJ071CGIgquLT1lRscqAPBML+kTgnM9HrKQeQq/lKtmc7E+vNsXm61s+VeC8TqERwXuBcD5wkQDa8AMJhYBqClKE/ZR44leUc//nW/oV3DACHWnwaNTylGgvSKKbrqXrIwTv1il3xGgRaiJ4Ly/3Z4wE9hy1HxOjhtYZyl1+xoV6SB93ckbwAZEE1enwM50RiXZEP6QQlZ46L6V0yUGeuLgH+ysaIYi37JfcSxi8/PMnbEXhXVdMtWPBsj7+d9MLGulHR47Yq98MKn6c+rBoNktqfQnV3hhS02VaMhEOzVKaz9UbySNZeqRGvZXz0hmnjuR5cFUWmwHxModxTmCWj9QQT3qMco63RoAMdUtPcofKgP80byWhP56JX5rqFmQCMZ4grzlbnVId+t9etdyXRYRUGS49iLDA+tDXIFctmBpm4idHNKTpQRsWCuD9ZMO0Qi2iPBbNINaeKU+ZKdf7JAG6Ou4hWsQHFUIg3RGkqpllVK8YCYex1Slux6zgBQ/ADifmxt8f0YPNqrwPTiJySk62ltpQcKVd/e3LQpbZnxs6KTsYZ5ehfbDpfOs6jAaM79fMp26Vn6fqWGrWtnPK8VpXm4PE6+kN7aJ/OJ9WWc+LI=
x-microsoft-antispam: BCL:0;
ARA:14566002|51005399006|31061999003|461199028|8062599012|41001999006|15080799012|19110799012|12121999013|15030799006|8060799015|3412199025|440099028|40105399003|102099032|56899033;
x-microsoft-antispam-message-info: =?iso-8859-1?Q?w81OyGTZGIxEfcd1gq3ayHEXrjldWKOVHnaQgvBieWTyDtgrECq91BVrYj?=
=?iso-8859-1?Q?Z977sTDdK9/YPpMXQWNip/2aZwNpkoz3uSy8FxyNwgVHPx+cMG8G418gh1?=
=?iso-8859-1?Q?LzQgG3lZgPrkca6GOIh2CMhQTYvKVm99FElKX6EQEC3q77tdWtnT9lGNdX?=
=?iso-8859-1?Q?ShnuNUY0bjpYjquPXWM96Umj1AyOI4UXedbl5BCdkT2V86AS2VPlKmTE0i?=
=?iso-8859-1?Q?hU19SRpJVbxyIR8/Rg23xCHUNsNBqiKBn/ZexX9aUaxVj1r5lnZ0ad1bR8?=
=?iso-8859-1?Q?0Qs1IIAiKUIMNvgNWcYSkRa2ues51NUkVygW5BC05Y6xYjir/TWkznAXPG?=
=?iso-8859-1?Q?rb/KwvOYTA92kl6QcNf5+uODdozB4FAH9ZfM2aQPjuSdWx5Cjr5waLLk63?=
=?iso-8859-1?Q?5w4zRzLyOKZjceskSo8/HZDpSVnTYF7oh5ZZThVC9D4g4+rcnf3VeSAyA1?=
=?iso-8859-1?Q?pC1AecrYiTo71jw4ATuOz2Gm6U1yIGMDToGAkG1X+mtszwd1XBExOwfSYE?=
=?iso-8859-1?Q?GC1EDTtql6RK5Rq6NBi25HMgQ/CSzoIgqg/phdj0vBCLGyg5SaqaERvEyl?=
=?iso-8859-1?Q?qY8rVw5fpRfs8Sb6KjdX1j9pjF48UjK4srEcmAvYP+MrmK1IwsawpypLYh?=
=?iso-8859-1?Q?pE6oodSpHY/8s03ccng2Ndm/7xzutzFk5ls03mOvodNNqXCdyFMCVUntxh?=
=?iso-8859-1?Q?AGK7cHEL6PDyUCktkqNg9j9gbmMY45SVNzuRQvipBhOq03jf/Csd34KzuK?=
=?iso-8859-1?Q?9/5D6UC+A/pRfsOny/3dD8IkXPLcL06hTkM3P6KVqabNfIf5b7QEZ59VQH?=
=?iso-8859-1?Q?3fqY5QbG6Ww5WsEeaAmmJGPu6ecrONnYGyFcozKx6DPJYhY0OeBgMLnfnT?=
=?iso-8859-1?Q?RP7ga69KHl7jEdY5jMpf5KkxJmxDX8t97yYihiQJ4xL9Q4aFuhQyFagHRl?=
=?iso-8859-1?Q?rudjwTbxJPZqrLOdo5i1Y2iFNIYvUvjvjf1puzv+3xVhByTKuVtpJp721d?=
=?iso-8859-1?Q?jbRId7sOfJRJghH7xZllLdmZAWCTtHLs4fO8flsuoZ3v3R4KS/yRktISgT?=
=?iso-8859-1?Q?zXg9BWvAbNzX9SGlPRWER8eEhgMH3umm7ijSpTsMUfySA8SQvHAkP98tS2?=
=?iso-8859-1?Q?PqC7Cr3/zChZJEUyQG5HI2d4w5al+MEjHtW+wN90pen1ySk60vAUJ0lktr?=
=?iso-8859-1?Q?QHN5A0MxQ8JshjvrpYaTAvVA6R1tarFBxvJ4pSLVun62HihOzpRIHeUHrb?=
=?iso-8859-1?Q?DNglAXCDLtP8M1ZlFL/eb6YbEoA0qZ5asVGxANnAjwAiv1K7MU1DkIt8jM?=
=?iso-8859-1?Q?PPcPoJhhxiX7gzB0zlggMLIXwA=3D=3D?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?7zZWzx8ih0VUwa7VrTQ6w1T3kHr2dJUvuDej3erILaVjOrJFHGTxh1N9zX?=
=?iso-8859-1?Q?CY/6NPwogf8Rlxov6XfC6Li4E9fPZ3JHqBOOeedsT59HWpsyYnZ3ZqQqDF?=
=?iso-8859-1?Q?URnlLpfrdYmBkNfzSWheapuCB6BJ9dXFUlQ7icK4E/sSLxp35OoDfjhdtq?=
=?iso-8859-1?Q?w8YENABJlkyvR+w0P2rCzegdq5BGKezWy4W7oNEBqGascoPjIpMZq5qFlg?=
=?iso-8859-1?Q?9zO4+8UN5DogJWD2wY9o83enGzxnm79FbuWgjU7K9vZp8F90qWFkrKSarq?=
=?iso-8859-1?Q?+1UpJY7/cWMQneuFjTqHyV5mWHfTjvSCidg3vo2H0b6QOdZy5K00WG09Aj?=
=?iso-8859-1?Q?V7+5Wu6rsA8/TzlM0/t2qj+Sh2Ud3prrUCeTw+B6CewDl4J4OwgUEBpKiO?=
=?iso-8859-1?Q?oi8x77T1gnmD0KLePhgOZcZKG6kD7WWsvAsVf8+9dX3ynJ92WTkXWTWX1j?=
=?iso-8859-1?Q?DO+1GSZajcFVhxfBiNFKIHLxcQbVAy9wWXIsDWUj75/6ZQmqHpXpn7qOVa?=
=?iso-8859-1?Q?AclZ8QMlE46W9M62G5ZxuooTtjPWARBfHafehP55f68699RMkHBdelkb6k?=
=?iso-8859-1?Q?uI4Uvwo/0/yIKdekeqnrRG1L5n4CAINsfJ9NEBHshFiFcMx8+vXDDVsaOW?=
=?iso-8859-1?Q?X3+u1Qax431RX/sAkTaAK1bOM1cmYOCWYhM/qma82bf0Tsmdg+nQZIc2w9?=
=?iso-8859-1?Q?bheAiDtvoyDW9QzoEKEZhEyiM7oEmL3kPNu7wpIyxnnJsFNu9FjaPWBgkO?=
=?iso-8859-1?Q?1Zam4/Ko9LpmLdCQd+FOyaJPRr/lkQz9Cvr0EPcdTmNdce7pIztU7nPliC?=
=?iso-8859-1?Q?5+TsaJeeWCh3FtZFZB2lWc8suEn0SCU4s2KExbVnMSrwEU//9yCwwpgj+2?=
=?iso-8859-1?Q?wI/8evDYMq6Egyb6ZXyZle4Zgxq4yE7Tewnm0E2B6iBwJI1+GLZCxZlG7o?=
=?iso-8859-1?Q?kultxRkhQ4V6kqwokGJR3sR4mC5bzNfChjTDDXU7um3jbNmuNJPMTtpOBz?=
=?iso-8859-1?Q?IQTKaCyLx5ha2ZmBt6lQkWkX1z5KetOL+1SRAco30qFXyR5yLMm+nUlAHy?=
=?iso-8859-1?Q?3TQE5vnD/zN2qh1sSffOis9Xv5lTaAXqcd3DXRwVhufrR0TXrvVCVPeAPF?=
=?iso-8859-1?Q?mZRlWuvONOAjzrrD9OQNJN9v617STGDSEDW3iD42HeMpXu2lWCztG+7VgM?=
=?iso-8859-1?Q?glvnP6NbKtsDZ8+lW3bJ/Qy1h7I1ZPvXdvebI+kVqwpCtXxje0LEJdJLZQ?=
=?iso-8859-1?Q?HuqddLEpsR1fQM0yyT5ZGyuOzblTfrVvjV7rMr1A8=3D?=
Content-Type: multipart/alternative;
boundary="_000_SV0P279MB044204AD0E554CC373630EFEC6A6ASV0P279MB0442NORP_"
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-7719-20-msonline-outlook-9812d.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 4aa65a62-783c-4add-d559-08de33176eb8
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2025 09:28:06.7935 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SVZP279MB0757
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79927
Cc: Eli Zaretskii <eliz@HIDDEN>,
"79927 <at> debbugs.gnu.org" <79927 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--_000_SV0P279MB044204AD0E554CC373630EFEC6A6ASV0P279MB0442NORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
> That assertion is incorrect: it would usually be correct if buffer-A was
> displayed in the window that's selected when you start the above code
> (in which case the `point` of that buffer is the `window-point` of the
> window, so the assertion should be satisfied as long as noone moves
> point in that window during the `read-string`).
> But since buffer-A is not displayed in the selected window during the
> above code, its `point` is fairly transient and can be modified to
> various values (e.g. the `window-point` in the other window that
> displays this buffer) during things like redisplay or when using
> `select-window` to "enter" or "leave" the buffer-A (which can happen
> internally while running all kinds of pieces of ELisp, as Martin
> mentions).
Yes I know, but please see the original email for more context on my
issue, this is just a minimal reproduction example that I wrote
As I say there, in my case:
- `window-configuration-change-hook` is set by global-flycheck-mode,
even if in most buffers the hook doesn't actually do anything
because Flycheck doesn't have a checker for that mode
- The minibuffer read with a temporally bigger minibuffer is done by
completing-ready with ivy-mode
- The `with-current-buffer` + `goto-char` is done by
`org-agenda-with-point-at-orig-entry`
All of them seem legitimate to me, but the combination of them results
in a bug. Paraphrasing what I said in my first email:
> For me this is a bug overall, even if each individual pice might make
> sense on its own. I guess there is a reason for the hook to work that
> way, so the bug is probably not there. Minibuffer completion changing
> the size of other windows is also completely legit. Any buffer having
> that hook set locally should be valid too. And a user should be able
> to use `with-current-buffer` + `goto-char` + `completing-read` without
> having to worry about something like this.
> So what do you think, is this a bug, or a limitation? And where should
> it be fixed if it's the former, or documented if it's the later? I can
> think of three possible solutions IMO, none of which is ideal:
> - Every function that tries to execute arbitrary code at some
> particular buffer and point should take this possibility into
> account and protect against it, i.e., this should be fixed in
> org-mode for my case. A solution that works and doesn't have any
> undesired side-effect as far as I know is to clone the buffer
> instead with `clone-indirect-buffer`, and work in the clone
> - Every minibuffer completion package or any other function that
> modifies the size of other windows should take this into account and
> restore the point if it has changed
> - Emacs core itself redisplay logic should be revisited to take this
> into account and try to detect this situation when running the hook
> Please let me know what you think. I can submit patches or update the
> documentation for whatever solution we decide (although if it involves
> touching C code, it's probably better that someone else does)
So from your answer I understand that option 3 is discarded and we
should focus on options 1 or 2. Or after Martin's answer a new
solution could be to prefer `window-state-change-functions` over
`window-configuration-change-hook` in Flycheck and in other packages
that might set it
Still, in my original email there could be another argument to fix
this in emacs-devel, or at least fix something:
> P.D: There is something that I haven't still quite figured out because
> sometimes the issue happens even if the window size hasn't been
> apparently changed. For example, I tried to check whether using
> `debug-on-entry` could cause the the same issue, as it creates and
> deletes a window which might make the window change. It turns out the
> debug window only steals screen from the selected window, so the
> non-selected window doesn't change apparently, but still that's enough
> to cause the issue too.
Shouldn't we ensure that the semantics with debugging enabled and
disabled are always consistent? I think that at least for the
`debug-on-entry` case something should be done in emacs-devel
--_000_SV0P279MB044204AD0E554CC373630EFEC6A6ASV0P279MB0442NORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> That assertion is incorrect: it would usually be correct if buffer-A w=
as</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> displayed in the window that's selected when you start the above code<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> (in which case the `point` of that buffer is the `window-point` of the=
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> window, so the assertion should be satisfied as long as noone moves</d=
iv>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> point in that window during the `read-string`).</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> But since buffer-A is not displayed in the selected window during the<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> above code, its `point` is fairly transient and can be modified to</di=
v>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> various values (e.g. the `window-point` in the other window that</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> displays this buffer) during things like redisplay or when using</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> `select-window` to "enter" or "leave" the buffer-A=
(which can happen</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> internally while running all kinds of pieces of ELisp, as Martin</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> mentions).</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Yes I know, but please see the original email for more context on my</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
issue, this is just a minimal reproduction example that I wrote</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
As I say there, in my case:</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
- `window-configuration-change-hook` is set by global-flycheck-mode,</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
even if in most buffers the hook doesn't actually do anything</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
because Flycheck doesn't have a checker for that mode</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
- The minibuffer read with a temporally bigger minibuffer is done by</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
completing-ready with ivy-mode</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
- The `with-current-buffer` + `goto-char` is done by</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
`org-agenda-with-point-at-orig-entry`</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
All of them seem legitimate to me, but the combination of them results</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
in a bug. Paraphrasing what I said in my first email:</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> For me this is a bug overall, even if each individual pice might make<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> sense on its own. I guess there is a reason for the hook to work that<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> way, so the bug is probably not there. Minibuffer completion changing<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> the size of other windows is also completely legit. Any buffer having<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> that hook set locally should be valid too. And a user should be able</=
div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> to use `with-current-buffer` + `goto-char` + `completing-read` without=
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> having to worry about something like this.</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> So what do you think, is this a bug, or a limitation? And where should=
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> it be fixed if it's the former, or documented if it's the later? I can=
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> think of three possible solutions IMO, none of which is ideal:</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> - Every function that tries to execute arbitrary code at some</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> particular buffer and point should take this possibility into</=
div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> account and protect against it, i.e., this should be fixed in</=
div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> org-mode for my case. A solution that works and doesn't have an=
y</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> undesired side-effect as far as I know is to clone the buffer</=
div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> instead with `clone-indirect-buffer`, and work in the clone</di=
v>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> - Every minibuffer completion package or any other function that</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> modifies the size of other windows should take this into accoun=
t and</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> restore the point if it has changed</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> - Emacs core itself redisplay logic should be revisited to take this</=
div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> into account and try to detect this situation when running the =
hook</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> Please let me know what you think. I can submit patches or update the<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> documentation for whatever solution we decide (although if it involves=
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> touching C code, it's probably better that someone else does)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
So from your answer I understand that option 3 is discarded and we</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
should focus on options 1 or 2. Or after Martin's answer a new</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
solution could be to prefer `window-state-change-functions` over</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
`window-configuration-change-hook` in Flycheck and in other packages</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
that might set it</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Still, in my original email there could be another argument to fix</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
this in emacs-devel, or at least fix something:</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> P.D: There is something that I haven't still quite figured out because=
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> sometimes the issue happens even if the window size hasn't been</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> apparently changed. For example, I tried to check whether using</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> `debug-on-entry` could cause the the same issue, as it creates and</di=
v>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> deletes a window which might make the window change. It turns out the<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> debug window only steals screen from the selected window, so the</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> non-selected window doesn't change apparently, but still that's enough=
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> to cause the issue too.</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Shouldn't we ensure that the semantics with debugging enabled and</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
disabled are always consistent? I think that at least for the</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
`debug-on-entry` case something should be done in emacs-devel<br>
</div>
</body>
</html>
--_000_SV0P279MB044204AD0E554CC373630EFEC6A6ASV0P279MB0442NORP_--
bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.
Received: (at 79927) by debbugs.gnu.org; 4 Dec 2025 00:52:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 03 19:52:38 2025
Received: from localhost ([127.0.0.1]:45029 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vQxaH-0008B0-Rq
for submit <at> debbugs.gnu.org; Wed, 03 Dec 2025 19:52:38 -0500
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51335)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vQxaF-0008A5-Ex
for 79927 <at> debbugs.gnu.org; Wed, 03 Dec 2025 19:52:35 -0500
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2BEBE81A06;
Wed, 3 Dec 2025 19:52:29 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1764809547;
bh=K474/maGregfj8LWroEKNVeX7/Wb+FAuwCRs2ey/p+E=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=NtU/CGSnKiQtqjgAyV+Bls+gS7uI5UenixgjwFNp7jRK8qCJ8JU7+sAXVdi9wJbSn
Ie1cPJwfTUrr8O7bMuEZ0JYefF29devhsdy4QyvRyyxdZmSUa/YKjr0ypV/64w2TNV
ENIqO2gAwUvMzZQJDmlXpd1GZKPkFSfPQBUT/644tNFM6dxnbR76bLIG/AThqAkQ6R
7zZOUQXWHgl0cxGwB0GPzrTuoZkbrg6Y96LNLDOYv6c3xvIrk/O2LPQGmO32GHWjZk
vYUxhSRQuoCTs2VsjD6Af2cAArYH5lLMP/CXtP045yM7ENThGNZCMC5WeOkyISTKC7
tz5i8WbqkczOQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 581FE819A6;
Wed, 3 Dec 2025 19:52:27 -0500 (EST)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D9752120093;
Wed, 3 Dec 2025 19:52:25 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
To: Ignacio Casso San =?windows-1252?Q?Rom=E1n?= <ignaciocasso@HIDDEN>
Subject: Re: bug#79927: 29.1; Unexpected buffer point movement on redisplay
In-Reply-To: <SV0P279MB0442CECC796A20B54473A58DC6D8A@HIDDEN>
Message-ID: <jwv7bv3dqg8.fsf-monnier+emacs@HIDDEN>
References: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN>
<86ms424adq.fsf@HIDDEN>
<SV0P279MB0442252DEC6BCBA711506547C6D8A@HIDDEN>
<86seds3nvx.fsf@HIDDEN>
<SV0P279MB0442CECC796A20B54473A58DC6D8A@HIDDEN>
Date: Wed, 03 Dec 2025 19:52:21 -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.233 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79927
Cc: Eli Zaretskii <eliz@HIDDEN>,
"79927 <at> debbugs.gnu.org" <79927 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> (with-current-buffer buffer-A
> (goto-char target-marker)
> (minibuffer-with-setup-hook
> (lambda ()
> (enlarge-window 5))
> (read-string "Please select enter/return key"))
> (setq actual-marker (point-marker)))
>
> (cl-assert
> (equal target-marker actual-marker) nil
> (format "Expected %s, actual %s" target-marker actual-marker))
> )
That assertion is incorrect: it would usually be correct if buffer-A was
displayed in the window that's selected when you start the above code
(in which case the `point` of that buffer is the `window-point` of the
window, so the assertion should be satisfied as long as noone moves
point in that window during the `read-string`).
But since buffer-A is not displayed in the selected window during the
above code, its `point` is fairly transient and can be modified to
various values (e.g. the `window-point` in the other window that
displays this buffer) during things like redisplay or when using
`select-window` to "enter" or "leave" the buffer-A (which can happen
internally while running all kinds of pieces of ELisp, as Martin
mentions).
Stefan
bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.
Received: (at 79927) by debbugs.gnu.org; 3 Dec 2025 09:41:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Dec 03 04:41:53 2025
Received: from localhost ([127.0.0.1]:39217 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vQjMv-0007JC-8v
for submit <at> debbugs.gnu.org; Wed, 03 Dec 2025 04:41:53 -0500
Received: from mout.gmx.net ([212.227.17.21]:45341)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1vQjMs-0007Iq-03
for 79927 <at> debbugs.gnu.org; Wed, 03 Dec 2025 04:41:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at;
s=s31663417; t=1764754899; x=1765359699; i=rudalics@HIDDEN;
bh=DVkJ8qfyT+vJtKmUPcihzHZLm/LflYQraX6Y2pwR6qk=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=fUaBCUp0/TK2ZIGeMnizdc+VBwRO3D6hmzrDb49BiQl+rVa2cuFdPBk26Hhg3S4k
bqNrLA+jz23UDBskOmGmARRwz+d+O8zTc4EOx55SN5yuCX8b/0qURdZiBHAWBX3ZO
R2lTdt8bIqyvZ3cfVC/rMDoWMYD1jm7OWthi0ihMjV6Ce5zFHXkOzfU7vngngyyLT
GF18iMkRorc5Sbpyem61X+2wMLyWxiBu9GW+N8F2OHA9gIO6LoxQTRuRuBbj66JCB
n96qve6tMBS8CQLe+m5g1K70wtBHpPMQgJvYTcYEhSsicBDS550TY3nM37CWitcSt
RgQMjz68DjJAhs7snw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.31.113] ([46.124.164.130]) by mail.gmx.net (mrgmx104
[212.227.17.168]) with ESMTPSA (Nemesis) id 1N7R1J-1w8ABS1oc9-00yppr; Wed, 03
Dec 2025 10:41:39 +0100
Message-ID: <b6d14d58-acdc-4a92-aa5f-eb144990246f@HIDDEN>
Date: Wed, 3 Dec 2025 10:41:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#79927: 29.1; Unexpected buffer point movement on redisplay
To: Eli Zaretskii <eliz@HIDDEN>,
=?UTF-8?Q?Ignacio_Casso_San_Rom=C3=A1n?= <ignaciocasso@HIDDEN>
References: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN>
<86ms424adq.fsf@HIDDEN>
<SV0P279MB0442252DEC6BCBA711506547C6D8A@HIDDEN>
<86seds3nvx.fsf@HIDDEN>
<SV0P279MB0442CECC796A20B54473A58DC6D8A@HIDDEN>
<86fr9s3juv.fsf@HIDDEN>
Content-Language: en-US
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <86fr9s3juv.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:fJ8zM583quVLRcQVni/vtsb7TUr7vV3zjttM0E8M1dyn1HSBCZy
/8JXOiThoHgBpEWwVhQYI5L2h38k8Pz9LQ/igCU3ruDr3S7KSaklJZW/ZOTAheDUfl7wy6n
VUs5Xs9hZPbkzLyyn+BTUk7cQq4iGzdLoSt8jOP+G4iqns8IUOiNKT1Zr3eFN9ICBgXjrM6
jhJpeSMbUiU8Iaj/alUBg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:DNCzHQEer4Q=;c4CfRwdNvkUVLkVnmWgliGhVFpg
6YS0Y2PxqolOGV6nedNJrIH1hi2oSSvyc8gWBUySHN1fTSr/dFCq1LPvfQJ3i2G94hQcW1QLj
3gUS8pSJg46IMgzp6C6eZ3oM9eBF5SdLrAIt03guRba0eZIrLdsL8TU7QYznkmB23jqEJOaRX
aQjQKBE41c8GzpF80Lm4sqtULLDEt76D/sZ6iKmkOmN+I3L43DVSPaTnTrvfWJtK2SHN8t3x/
kTR5QVPZzAr/JjQEeo+pEP9bYCRVsuq0ILDTcRgktHITp9gNkzCi8MIxnTkUpWyvp0fPiREan
IoofCxa1OUn2B0+VhB5l1IvY+zH73qF09J6kJO3zqDwQL+AZibddYfq1gplw8L4MCdhYOs+Ct
L5We+NWDFCd972SgNxPiTDrCNZTW0ZQQKjZTBq9WWyMNTyk59OjyVmd/eh683GheA1FBIAYtd
FQPyq7B/GrwaXBNDbPsA1TeXTFQG9Q0j5NGPhO6fHm1L1Mip7kxRxV91a1abfBfyyCtt0NJoJ
Dc+g6OK2EV4Ekb7hB4FazRo0JHMtkMqVS0i9mQvxIMDZS2paVGhNXYlGWobyKhx8Z0sEII/kj
MNukmCoPwjrkn3rX3Qnpi0yHUjtJZ4ScSIDi4HseLYgameqSjOW6uw9cSnecVYxJxN64iusz+
odK1lvcPo//ATKgRG8nTC9rkdqob7qzmlYJQkshAqOXxOJXNAma2MuaKLl5Pxin1a4IXMzF8P
5xduRt4UTlR9vBRXzbpsHS5C/tG63RFIYg/co4dJmQ45rTE3ghbyLwGnQURTiLGRz2kqTE2QY
RfSgPRGJ8A/JmUYm6yes53Ad85MgwTs9l0xLM2zPdGfG7t8AOqDWqG9XcH4G8Qbz+RaOU4AT+
hqqBU6sftmgtQSYqC8BFPfmNl4/n3dWYnlslfwGmOZUdc8fG+vdG7zZFG0bs4WcTXDiYPwxP/
b0QXvvnDyDfkNSQjGSdhUPQybiFX6M1sCaufHy5UxR16jYNd9nHnGRNnOpcm4fys+Ih+NyuOk
Y88QQ2H8+ECbHjQeM4KcsVz6eZL8BBMYShzeqefD7wNdWoeYf8YO3kRtw3Uxn/Q4IiyQp16IE
n6gFKIag5gp7eQe/NzlpW6I0ANrLRFb/bCopN8/Pz2t4KHxi1cZhFlDjMbprJ+/otkscSFYAh
yYr4EPKO7LZIIXv5Fs0LCY/0/O01+d7LaIHsA5pRDjwO1iEOnVv/81T/jwWrtDPgxa8UEk+/l
IpLmK9uOCtNfLooy5Owyx2szKIZcMW28Bhtp2pYzYzY3rNwVzW25991BszDjdB/4TNVMWlja0
82Esyh3tpGOI/etoFEWKdfNYxXFK+HPkIFumXwNsG95/dDB3ngcPzCLTrdqzX58nJQjPhv1Y+
X0STejviAxjw8t1Xwm74t2yzbY93esK23Q2B5OtFIEjBmGSATPsLtAhFQOmjDmceOhTomO4cA
GXZI+9l96Zz8jhhQ8dy00aIAaqIHg0BfY4ErgR/ZXXDAbIumv3Op+Kc2DB9qtzM6JEcdADaeZ
pzcIOo1LiVM57FuD/GL2DYc4k7ZznO9zubP7NHN0Up4V96qw9ouyvyh1DALVmxDySYlIqWSW1
bZWFoPF1VhdkZ+0oL61ztSLVj/MgSE5BqOJYp/bRHIvVTTsV/MpCpw4w/07YVLiE1r0U3LUvQ
Wjb5mpG+2A+BD8gD/mJFaBzkfh1OiryWtxUR6kwIeZ6QP0aKyisAU5kB3MMSWnPmb13qx6ZC4
4DpjfbiBctU+QYaV8w11zf2/D762LZDaAJ3a2gNcrXtJUEnekmgtiO+MdmW+2jsKBV8oEgoSj
PBSE5U9joQQiZWI60fgg6InSK1uZx2cuyMSCr9098szJgKwHnT2PE03+ht4g5f8G+/NPzvqNz
dL88eqc0HjalPoh+ODVni8VBQcSa27aIkeBt9GhUjyl0p6/eeaMSFhApLHITMwRhaUuFDiqvE
Gqp7eRNXI9Zoph57R1MQJJBCMVa+AwlYORyC+PP9KGQBoncojKCmPte9aUG6iM7czv08JPzpZ
odIv2zpfQTQJUxW9KFXan8U0oPeP6NP54A9TqqZ5cdQhn2FaE5fucM4ArfKFQKIig32TUWGMs
BzLJh1cmIUN9bHItW8dCMDLidMcYrf3VTYDNOIIaC7V+lWdVWk6TlvelkE4xp5rtav+2rQw45
5EoCCdZRYzh2ab1jXkTWGyT4tMpXMQDWA9QzXt9K/eQpf3HqjRnPs+b4mjXl0zNrZDXICgiv8
HCkjIunh5AgD8RYd/Q2TFtdhjTXG6YHVjpF5i2yjyxo6XlkJ2fIpdYNWu9JglQuTeS7yLfOfc
olN2X7fZzlz8awt3Lp+x/4MShUqhAvIRcr3Y4poDwbil4Tv2tEfvpszY/hAEye+Nmy9txFWon
V9w9rGWDHM8fLgWDU5Zw1NEYffnSB2CHNbrONNf8r75lQs74C9Z6GCYFvKgvvxsi1FXQpEiuu
SewtHYrYcKwYK8eFfEz3XNB5EtJv5fESHyXfn8W5NtNpKNw1X3AnklMWo+LH1AwWMlacjWduk
ckiUW0vKXcsnZICb0veBBrLUxXWAJY59/lpvPoy5EYLH7meSNdw8c56DvfYSddOUisTQriKaK
5NIEyKQqOln63rLh7H/kFmh9i7iNmDHuMGASyWCJq8YBWT/LTxWgJQNFgGt25x+ScAy03nfkA
aUSuvhSn486qjAlzDyxTwXkwWOyJjd3iRAf+/Kbkdr9tdvdNO9zysrXhTTu/O4iFmyXFE1xhd
YE35gc1TfaWy7eGopvdAZ5rbvYpfAEcoUjd0pWmW1WnCZHkTCSouAs+EjgQY0GD0HkO/v6y+f
8a4/hilHmkwWT0l3vIYQC2RMnX6N8KdS0gpjU+HRjZzrTYRtj2ry41ID2KjmXpKI845CDRMbT
gMZ0lLBepNZ1csCEeQWXxJhtYNwqbFt9Ng5RxoFRPRc4z1Tnea07Wwu6YoBXycFU1MmIjSvQ5
S82TM/OczkY59fkCCHD9qaGiIITYySwoeJInCl0KU3JSimIB9OaN7PtlcR0zaSZPoI64RuN0F
Z3FnElHjTgk089aemqqf7aPwMCDF9LOZvmsNeK6IgF+WJ8G+fKCHv7uGcgN6TYKnklF3hdiUU
+csIxE+sK8mSIoIZUq6N+QtfpA7AcMTeI08EO2j0XA1K9WF9XUfO2wqIG0jY1kEzg0dfXqncY
p1bkdDp9N+h2odo4CgC2W2WpHQrHgFxKo4AxWMAQDnD5p5jkyjhOGav1sgaS5qiNyHCpo7oMB
tUr1o78Vir+S1EbeQB5hy1mrId1E2iStxah1Rz3I61xuHn4q9tjeLJ5/ZFbYxpqs2bVe687ip
8l4oD3s7wsBe0RPYINzkwXbcafhEqgf9pBfk/szxEttKAYRZcZevf5yV/gpn6SXeRgZm/9Mge
8xJ/0n7cSwRtiS6sKCuq7LaWi5B2LGYlShoS0s8VPvt0xSrVW8htvdWYb0XtXM0qm2ofvNxd8
Ys0RDyGlKY26Vo9O+zWSNm+uRz4eUT8/FIncfMY3tpKPxt1tyvK+xrK3Bhi9aNzLLjHEYBelb
MYmCvMeEG1YbKWDgL8g7KTOTOn13zB6sPE2wFxAA1TyUr0YNtoMI8Jd4zIrPBziSGnZp60nfE
TQPOn/XBOLdHHqYxjervSTiBXTs3LUBNdMUU6FrDn5ShamL1y0FEzr/pfUgLGYMmyg3uKnRq/
2vNXrajZmNJWNfAxrBe512rWnHNacGytVSNj8lJyHvuApyE1y0aKyvnJJKslm3JG/hbZCXHjW
R2ngC7LtkvNFG63E4VsHHn2kOrC6tgmPISHpGwrU4HYEMYLXz2r2q9NW3QZU7l3RkEYty2+hg
oxyVtOTfpay8fM3Oc0aXYfPf6KkhrU9cit3nCyh/7fBJeejlobiNoek5f+ukY3SEY603/3KSR
NXrQ5Fay0E6zRIXlBqr4GzqTqLvboBxTE4PmvhmZYN0LInMWX2lUN1C5uCUfPMOy62CPv/Zuh
3hAZSwZbYzNTHmloXoDRscROfpkMLnPtdBrJCQ1dXQQMFK0a+8f/lsBzBm1B1zjRWceuJsTMz
j7tVqyc+asGm4YCAAgK9HVWbSj3gly0La7YIGM1cyTlT1M4kSPngr6DkExAbHIbQQeYJEQims
icMyOYXKlB7/Sjgv73GvNSzPFl6xOlSrfUlg/7xu+B8T4gNIW+H9htEK5Pi9cAD3eMjacXfko
yhTp9WX2YLmwBX62BVR6ZIyk4Q821tznAVf7YJxu2puE+1r128F09SqN+0RuvYJh8Ia8mknxT
m5Lg/TaOjtM8Dueoiw2f7xpUnIAmaebSV2zdsgw2dZOiteuc9AI8cBdzC5c5XdtQB32Ybibl+
JkHK4LY1SinjDqucJlejI90kGUjkT2eSCCs9qqEXVL9Q+ex6Hy5hVM+HOW46jWXIgVgYzZvOJ
8gp09LPVOVzyiceMWZhuPQq0a8CtVhu4CNZiGPRnK5rgEpTcT5+DzB3sQyzmwUZrXp0vF5Z62
2/n7DXsFX1SuDq0vnGv8cE0M/iQYhDaS09WyCExNWZ2RWdVi+ClgJ9rN08Pvq+48v7voHXY64
Ghmg2GJ8gAwODO+v0pqfmoTQxN2kJXvNukuVQ1ixnRlLsUqXxL4Oyu045Zb+lVw4DNzSpBysW
wQosRUaR8/JjwNDzrjw+AmHLCQauGU9nRR1/qLjr4aGLjM0pLirroF6xBYifeH7see1YfYQhP
BVIGgwhyABdL4HzNaw1z5KsZAhxoYq5VlkFMDyjO6TALMtxLnvTNW0QGgZ6h4r2wiE7ykjow0
qcYIIociKfy1WWTI9CekAjHKte4XWs1RBk2/eZW61zEUyogmKDLRhMnQiADHb2ZPk7zVnErn3
gmdmuu25bqy0w8ffv3sNab882mkzimLS2PFasvCmLVanMNPfb4fw1ZIGV7jRtX3ltXhn8/rR1
SNmUdrBpnZYpt5uEl67jOoHWWRvWhI62ubi6B6CwSe1V7YxBWnuWZomNy2aKzKkPmV+NOPRD8
cqz/POoZTPGWTEoyxsoCl3Y12+RpGwyPJ5LqSnqgczgqXuabns3zE9CEvZWluzK4ivPucw+DS
K+5ujj+hNxmQgU3WiPsE889wnX/RNaCkwWB4pJY1p6zE3p0HqwDvHFMZqw5PjtEXqqg1wA2ed
u8VdWCB9l9uXTFJFYriYRRyIqiO6VWiNDiJ0ljC4yPONwjj9lQFE7Snm59tQ==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 79927
Cc: Stefan Monnier <monnier@HIDDEN>, 79927 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>> (progn
>> (switch-to-buffer "buffer-A")
>> (setq buffer-A (current-buffer))
>> (setq-local window-configuration-change-hook
>> `((lambda () (message "Hook called"))))
>>
>> (insert "line1\nline2\n")
>> (setq target-marker (point-marker))
>> (beginning-of-buffer)
>>
>> (delete-other-windows)
>> (split-window-right)
>> (other-window 1)
>> (switch-to-buffer "buffer-B")
>>
>> (with-current-buffer buffer-A
>> (goto-char target-marker)
>> (minibuffer-with-setup-hook
>> (lambda ()
>> (enlarge-window 5))
>> (read-string "Please select enter/return key"))
>> (setq actual-marker (point-marker)))
>>
>> (cl-assert
>> (equal target-marker actual-marker) nil
>> (format "Expected %s, actual %s" target-marker actual-marker))
>> )
>> ```
>
> Thanks, now I can reproduce this.
>
> Martin, any comments on this behavior?
When you put something on 'window-configuration-change-hook'
buffer-locally, Emacs will select any window showing that buffer via
select_window_norecord which calls 'select-window' when running that
hook. This will set the position of point of buffer-A to the position
of that window's point - the one produced by (beginning-of-buffer) since
at the time that window's point was set the last time, buffer-A was in
the selected window and nothing changed since then. The 'goto-char' is
ignored since the selected window did _not_ show buffer-A when it was
run.
On exit the unbind form of run_window_configuration_change_hook will
call select_window_norecord once more for the previously selected
window. The position of point in buffer-A will remain where it was set
by the first select_window_norecord call.
When I replace
(goto-char target-marker)
with something like
(let ((window (get-buffer-window buffer-A)))
(with-selected-window window
(goto-char target-marker)))
the test succeeds here.
run_window_configuration_change_hook could try to save the old position
of point of its buffer too but this is not for the faint of heart.
Let's see what Stefan thinks about this. My personal recommendation is
to use 'window-state-change-functions' which never selects a window when
run buffer-locally.
martin
bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.Received: (at 79927) by debbugs.gnu.org; 2 Dec 2025 16:54:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 02 11:54:26 2025 Received: from localhost ([127.0.0.1]:60893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vQTdx-0002uv-QU for submit <at> debbugs.gnu.org; Tue, 02 Dec 2025 11:54:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52046) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vQTdw-0002uk-BY for 79927 <at> debbugs.gnu.org; Tue, 02 Dec 2025 11:54:24 -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 <eliz@HIDDEN>) id 1vQTdq-00079R-Q0; Tue, 02 Dec 2025 11:54:18 -0500 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=XB0p4Vkpp2XCVC/5eQeYp/yaBzhRsEalQbQEAAaz5Iw=; b=RFsjBSim+DdNouX5xr3I gpUlNqqtElGjjkRu6pJ7HxO8ArFhAMBsqRIrZ5MBLnDcCuJ4vy4dJGTBEv7kODvOl6ie76p2GEDif slmE8g8j4ATuzv1f0sBkJyviPaHDdQBKe+CSVxPlvdtc3r+grcMICmOdsP++OeVR3bUpL75y243o3 iqztCbBUkMoGMd1aQg1wUFIGXH/2MBJkm1nzfZjkAK1g/vgZq4Zmwob+IZKxwKgXSsqOfCx7QS7b8 y2buY2Bn3RmF3RXnm+sp5zp8o+otCh7RhlA4k/dhqCZg4Joft/1h8Ml1eHSVi5q8ySvMY22FrJi3+ g8zsDbEUPY+QHw==; Date: Tue, 02 Dec 2025 18:54:16 +0200 Message-Id: <86fr9s3juv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ignacio Casso San =?iso-8859-1?Q?Rom=E1n?= <ignaciocasso@HIDDEN>, martin rudalics <rudalics@HIDDEN> In-Reply-To: <SV0P279MB0442CECC796A20B54473A58DC6D8A@HIDDEN> (message from Ignacio Casso San =?iso-8859-1?Q?Rom=E1n?= on Tue, 2 Dec 2025 16:25:57 +0000) Subject: Re: bug#79927: 29.1; Unexpected buffer point movement on redisplay References: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN> <86ms424adq.fsf@HIDDEN> <SV0P279MB0442252DEC6BCBA711506547C6D8A@HIDDEN> <86seds3nvx.fsf@HIDDEN> <SV0P279MB0442CECC796A20B54473A58DC6D8A@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79927 Cc: 79927 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ignacio Casso San Román <ignaciocasso@HIDDEN> > CC: "79927 <at> debbugs.gnu.org" <79927 <at> debbugs.gnu.org> > Date: Tue, 2 Dec 2025 16:25:57 +0000 > > Sorry, here is a single Emacs Lisp expression that reproduces the issue, I > hope it's clearer that way. You can evaluate it anwyhere, and the > assertion should fail > > ``` > (progn > (switch-to-buffer "buffer-A") > (setq buffer-A (current-buffer)) > (setq-local window-configuration-change-hook > `((lambda () (message "Hook called")))) > > (insert "line1\nline2\n") > (setq target-marker (point-marker)) > (beginning-of-buffer) > > (delete-other-windows) > (split-window-right) > (other-window 1) > (switch-to-buffer "buffer-B") > > (with-current-buffer buffer-A > (goto-char target-marker) > (minibuffer-with-setup-hook > (lambda () > (enlarge-window 5)) > (read-string "Please select enter/return key")) > (setq actual-marker (point-marker))) > > (cl-assert > (equal target-marker actual-marker) nil > (format "Expected %s, actual %s" target-marker actual-marker)) > ) > ``` Thanks, now I can reproduce this. Martin, any comments on this behavior?
bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.
Received: (at 79927) by debbugs.gnu.org; 2 Dec 2025 16:26:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 02 11:26:12 2025
Received: from localhost ([127.0.0.1]:60759 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vQTCd-0001PQ-Q6
for submit <at> debbugs.gnu.org; Tue, 02 Dec 2025 11:26:12 -0500
Received: from mail-norwayeastazolkn190120002.outbound.protection.outlook.com
([2a01:111:f403:d20f::2]:16587
helo=OLAP279CU001.outbound.protection.outlook.com)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ignaciocasso@HIDDEN>)
id 1vQTCW-0001Oh-Vl
for 79927 <at> debbugs.gnu.org; Tue, 02 Dec 2025 11:26:09 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=hK6S3qVqLAbaoUR8N8oaGQxofrUicZ5pNijgPB1hkcNeS0CswmtdjSYhEsvbqGBz6oxcQUMbhFL4YHHqM96W7zKMpUkOE8q6jkQR/wbjaJUH2RV5+CmEQ/0km0gYQQjL3lYsoX/qoRA6ZVp0ypwHSt1hnqs41XUEtz55fU920IXherbturinlbMO1o8Vk9lCpla7DWEYCXvN7I8+xy8GfhwRoTuf4MHZJdMart5OkDF0DkhLPRDV1HEd7Fvbc58XDOlzjf+LSM97zFjJhJ5MdQWBfGS8zCOW5kmh0CdQfMldhziEseDrEkzWuXbbNvvfa2utdV9EpjYkUS1WwF8PVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=ACa0F6XZyTjT6js7t2y9chzrd+i/d41y219Mq1rQX/w=;
b=K7zxtDBLz0QJBOySs1GzNLBLuBOMnIbWyPUQaNBzShXrpcLEoxatDrvS0ptHvozqOgiah8fsNj+gNN/SJfZa18kx8AoVziTYakPL8dENelP71jZaTEd2LuKYPVRONwdVeOkPi5OrmP1J8zTpMSX9KAkAEhu7HkWmr8p+hzi76PK5kzuhW8WbfG4NdW7yrcaL9baSqVFT+XHPEc6D4p4VR7ws72AMG6UFkeMwr+IzFKdZQX755WP6NRqvPSy4gTvpS6HX++LV/X6mpScZ60FSzaNeUKSElmAq3wPZGAc2CuI9LU/KEMZuWzR4YHR+pc4Gjvz5r48eIc+ncJXTiXBOWQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=ACa0F6XZyTjT6js7t2y9chzrd+i/d41y219Mq1rQX/w=;
b=ZoRj/dmlP/QPNOgdtWJinKQZxM/zqAxrceco3dmxpMO5siILvpdxjMh4JDEYYWDO8iTv+lehEZY9wOg1+t3jOCcfwiYnKcsqLyCE4hl0AN5nrM+dxzJJs/8JGlnRms+h2pa8YlJH/GP7ZqvF6uPEHxClznkB4lU6O0vKoETlbItQx+is7IdnvzEV8jTxYNUnxixZHCaMM9xZUOeCI+BVACiohR/n78lk9YmmCp+kBRGSnuUczoAvs3q3t5sRnC3tICGIa4fyYHHMhREWbmqYUxdltscvKtZcWwrqt/LyMa210o9DJ8L0I/CZE8QkFAxAjDfTFP/ty8HILbSt99sfaQ==
Received: from SV0P279MB0442.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:19::11)
by OS6P279MB0524.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:2f::7) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9366.17; Tue, 2 Dec
2025 16:25:57 +0000
Received: from SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
([fe80::e7dc:921d:1322:a269]) by SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
([fe80::e7dc:921d:1322:a269%7]) with mapi id 15.20.9366.012; Tue, 2 Dec 2025
16:25:57 +0000
From: =?iso-8859-1?Q?Ignacio_Casso_San_Rom=E1n?= <ignaciocasso@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: RE: bug#79927: 29.1; Unexpected buffer point movement on redisplay
Thread-Topic: bug#79927: 29.1; Unexpected buffer point movement on redisplay
Thread-Index: AQHcYrs/ZfHPjlDt8Uazhj06KM3jFrUMwgERgAFUMSSAAGSn54AADYmz
Date: Tue, 2 Dec 2025 16:25:57 +0000
Message-ID: <SV0P279MB0442CECC796A20B54473A58DC6D8A@HIDDEN>
References: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN>
<86ms424adq.fsf@HIDDEN>
<SV0P279MB0442252DEC6BCBA711506547C6D8A@HIDDEN>
<86seds3nvx.fsf@HIDDEN>
In-Reply-To: <86seds3nvx.fsf@HIDDEN>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SV0P279MB0442:EE_|OS6P279MB0524:EE_
x-ms-office365-filtering-correlation-id: c4807be5-3d61-44a6-7b8b-08de31bf7934
x-ms-exchange-slblob-mailprops: ScCmN3RHayFtxMbAS/9UNk9zI/w2eG/3YFh87r+xwb45vFxjCtiiCVK6RvNU5eL/2bjTklzExH26Pb9x33sZYj2c5jM0rCOumZVoO/x7ZGn7nYz7cugkpyW403GTwJcc5V8jsP47zcEfpLZT8xHyqGi4jOCC3K8XaBIjhv9ELBi3OSsPO3m1iTr+TJC9ffil91FiHx5CV+wznyj0Bobh5KFUJiuhkkxysuNRyl8zIXOpd2209tamDDceqmRtpF7BN9hlhUgcY6uHeKFalqld0vQeDv3uLNk3n4wqDq2ORpo22tgim2ocQ8XFJbMxz0eojMS/0/rBQi/ZpvW+K1GHxMkHk3ldWeR7gsQt5IeofXbSG+bu2A4s5MKt4JcoUWbS9GDBt4eSEmlXLDmpRCsVj9lr3Qhep59afQAJP1p8J0cPGcJSp81k0aIum+mQb8NAfFBb90mfsJW8bX9u66Xw6ai7AVf1yinb2/uCMW54wPmMhl7rj3drDdpkUR/Yi06qcmxn0S3xss2YZW+bt14O7MKHyDRj0aKtr14HUhQHC7JxrG79T2JFnQfFKqwoATHCc6/SUWsq3/Dhe6luw0TnqtWAm0GbUtijLcTo+M6/6eGvKON59H8zUxXxGI4TRhxlESyj4uAWwd3OypZT6uyUgF1+uoWJPjIqT950nJREQWKgr9BABDzbJzWcXydKCqW8bNrCPjaXErQis1bizZvn2HZr/SnnN/dbhJTMt3MduTk=
x-microsoft-antispam: BCL:0;
ARA:14566002|31061999003|8060799015|461199028|15080799012|8062599012|15030799006|41001999006|51005399006|19110799012|440099028|3412199025|40105399003|102099032;
x-microsoft-antispam-message-info: =?iso-8859-1?Q?wMTJ+cXKJFPp6EyWKQ1JmgE2942z1vOhIwSzo3K89olzGravv2mdgi3fGJ?=
=?iso-8859-1?Q?HCUz6WbTQw1p9KDAqjFP4RDtZ5WdO7fKU56jUYpsUwUe7SivPI2BVt5Pt9?=
=?iso-8859-1?Q?im+zHd1kOVPP3KX6Sil3a7bl1jnaq1YlWhFlQVNasxP//0YU0jurnDgBtb?=
=?iso-8859-1?Q?yRFcBmNg/H3C3PwC8wYmSaNzz7sqyIZ+Bz1FLisneZjNjpBNOK2k5jCW54?=
=?iso-8859-1?Q?N4wwAxOKIwvN24ByQHTwyxPUtwhXKO+kjltx8tgqtNMiOzbq5RldTrO8b4?=
=?iso-8859-1?Q?aDmolymGqJGT0BqHE/dUSidNtEAdZJaq+F8ernSRbzt98+js4EbMdc585T?=
=?iso-8859-1?Q?rdT5ybzQjMdrOrJKjPo006iFdWD/W68mLUAhkAZkHlYQ+e1FiAtl1QgmBw?=
=?iso-8859-1?Q?6vUU2X6PC0MsuW6eUBIv8eOFPgcWKRUAx2JfTKKTS4iKwKFpFN39o39cPU?=
=?iso-8859-1?Q?0yRm4Edf2lPCZYJSW+53OIBHezijZ0L3UggtKbNWu717caxIjWGZM/y1qb?=
=?iso-8859-1?Q?a5YeTSGyx2Cx+Iyc3Xhes89wD+b0EN/UtB3Y/BpCFEYxH26o3egPDrdkGW?=
=?iso-8859-1?Q?5XU+U72X0EPXAPGilgCOZW5xLwpTyUKm0GkYzKZeMSFbiQZ4aq3N2oA32B?=
=?iso-8859-1?Q?mOygYbR/y4A5OzdP+pdRBIqS3W5t+Ai6Prvq5FX3S+xyEtZ7GtWTXYi32Z?=
=?iso-8859-1?Q?0S0RPFZ1dSxfqCJYMWPgJC0uZDuN5wCs+eSxDLEdHk/oEKCU4qWFfc36Fi?=
=?iso-8859-1?Q?mjVt5irEtUIsnhPjJYIAOz3IsgBIlrWVlePqopB8u/3HMGzkzeerU1zzc+?=
=?iso-8859-1?Q?iHH/WgFKN15otg4Aac4PCSkPcNrY/h1Zlc0DNeyoC2E25lQQOaqZPpLcra?=
=?iso-8859-1?Q?j7hdB3rqehfPE+pyIUyhSxmyZNiMFZWQI3rufGx9vytuj0PNhD7ipewAr1?=
=?iso-8859-1?Q?EHkrbzx8joS7SYCaM+wjkMZ4PoLGlCTTgdLC02Gy4l4aVUUDL+KkE+kfqP?=
=?iso-8859-1?Q?PDE08ztL00UUSFHpHxZxho1OHAeFgR9zGcjgBq7w0/PQtsOA11cOJu61G6?=
=?iso-8859-1?Q?pYa2NoQxalzW5+QSEWFzZZBzKnHYO9uehfqHTczj874BIWRiyywM41rKKY?=
=?iso-8859-1?Q?/K19f4BGWDd383FVR4kYXdC5Cr5nIPcXP+Bon6+1Fqm/wVpCirFb0nSuCP?=
=?iso-8859-1?Q?SSLxiiNEM9wcfKXRcVwlDXOoPWRDqqpo1cfk5hbXmbY1ph6gZ1y7s+bTY4?=
=?iso-8859-1?Q?c1t4Qj6dk7P2dh5hPzmEXmg4IALC9v326BZ7hTSB9JC2BAhGiCX/0A73mC?=
=?iso-8859-1?Q?4wMZ?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?i1cyHhVp9LogKRZ0/iAb08ZS9iDHZB1gIDgu/YdHUAMwMiHDEC5SN/QlHy?=
=?iso-8859-1?Q?/zdL7LX65wFIKqJIjYc6Wtu2iHaZgjInJNzf3oxRWtFjiCveRllT3V6ifj?=
=?iso-8859-1?Q?pwNe+a+TSilUwzJ89T01NYqQ4BufpxQkoBHUCxe59jASVUkN1enaKyrN4X?=
=?iso-8859-1?Q?22uKo0+Hg/q8yUX7TmDNhwqcK0HaFJUUkJWrsMA5jfECt1QUNTUQEFlaW7?=
=?iso-8859-1?Q?FsNZ/WwMTdyWSmJgzZwsw6NHE1sv/xudWVRSgUblKwOBtHXWv8kkWmktQE?=
=?iso-8859-1?Q?ouLSbAy8aPo9KyEX1T1u7Nd/xXngAiIIxteRIgiOtXtENbHKvqvmRLqtQH?=
=?iso-8859-1?Q?WzNSy8WkD4mdz9EVeU5BmtKLmOaxHArXA4bPRXtF7inLp8YmLoe+KzKuCC?=
=?iso-8859-1?Q?rETNoRY1VW70n+RJhZX67OUXRVTSHBJUREAZQ/X/Up30QcMl9x4k/Ldk6b?=
=?iso-8859-1?Q?+LNrhzVLw5t00tU56oOIHh1Y5nKal6cezskHmXQ8BiEqvZNfGubqT0YCNh?=
=?iso-8859-1?Q?6wt3xRFvgunkY+aKNC835qNpqx2NnoCQXQ46VBlFwh448mwHstiCDpoWUE?=
=?iso-8859-1?Q?UM0TBh2ji+e4+ogR34TCuUEFjQsEaP+SyJ5YyTxJZszhYhfg7xw0E3N6Rs?=
=?iso-8859-1?Q?xvn7wOO9gwYeW/c2mQune6kCIlt0HyWV3dCjQiezTyQvAFIn1RxQKA6zSB?=
=?iso-8859-1?Q?phSKrjIgmq8+b+UZ0bVXbDbPuLORhMDkZ/MQkFnyXRI1mJ+7e0fjD0Nm+J?=
=?iso-8859-1?Q?dgaGO8OesYlIxlf+TAflWf5kJoXcLXujLKAyhSXYnzV7pUm90umZhxX0zw?=
=?iso-8859-1?Q?Oxg2eu8O/hc9bhlUaZyB4UB2uvA62JAPFFPaVdiw+1UePQb3OBjWXNCEgE?=
=?iso-8859-1?Q?c+ZDD3rDag8MaXvqm0Ah5xqJYaAKwG4D/IFJtQ+vwc4KONRj8KxbzG1WUG?=
=?iso-8859-1?Q?y9HZ8NxnW3T+x/z5ZG0FIeWOk9nYdz0eoS/gnT0OWD++KxnWZvuiHd+qEZ?=
=?iso-8859-1?Q?6VGzNv8VyQ+YWSWT9Byl3v7IUR8Oq12eOcZafeNH4t4qqL+04GozF5CMB+?=
=?iso-8859-1?Q?XsE5n6byfjpg7tM6eA54BDTm5aoARszlAFYJlNVHn1ORCtJ8OAzEES2mEO?=
=?iso-8859-1?Q?aHpPx5fwE1aYGuWHYM46tGA3UNHQf5R4xu/CyYIU1WeOJYpzHSu8nSd/m+?=
=?iso-8859-1?Q?1esoyPjshmZRz05HOycxyvOf3ggTgDuoJG2UGpm0QeWQja+zwVdEVkvwIL?=
=?iso-8859-1?Q?Kn5DqjuVicRZe3QsKQECM/kH7V+4WhGp3mXlW/Spo=3D?=
Content-Type: multipart/alternative;
boundary="_000_SV0P279MB0442CECC796A20B54473A58DC6D8ASV0P279MB0442NORP_"
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-7719-20-msonline-outlook-9812d.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: c4807be5-3d61-44a6-7b8b-08de31bf7934
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2025 16:25:57.4566 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS6P279MB0524
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79927
Cc: "79927 <at> debbugs.gnu.org" <79927 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--_000_SV0P279MB0442CECC796A20B54473A58DC6D8ASV0P279MB0442NORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
> In that case, I did what you intended, and I didn't see the problem.
> So please describe the steps in more detail, and please also show what
> you see that indicates a problem.
Sorry, here is a single Emacs Lisp expression that reproduces the issue, I
hope it's clearer that way. You can evaluate it anwyhere, and the
assertion should fail
```
(progn
(switch-to-buffer "buffer-A")
(setq buffer-A (current-buffer))
(setq-local window-configuration-change-hook
`((lambda () (message "Hook called"))))
(insert "line1\nline2\n")
(setq target-marker (point-marker))
(beginning-of-buffer)
(delete-other-windows)
(split-window-right)
(other-window 1)
(switch-to-buffer "buffer-B")
(with-current-buffer buffer-A
(goto-char target-marker)
(minibuffer-with-setup-hook
(lambda ()
(enlarge-window 5))
(read-string "Please select enter/return key"))
(setq actual-marker (point-marker)))
(cl-assert
(equal target-marker actual-marker) nil
(format "Expected %s, actual %s" target-marker actual-marker))
)
```
--_000_SV0P279MB0442CECC796A20B54473A58DC6D8ASV0P279MB0442NORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> In that case, I did what you intended, and I didn't see the problem.</=
div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> So please describe the steps in more detail, and please also show what=
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> you see that indicates a problem.</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Sorry, here is a single Emacs Lisp expression that reproduces the issue, I<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
hope it's clearer that way. You can evaluate it anwyhere, and the</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
assertion should fail</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
```</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(progn</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(switch-to-buffer "buffer-A")</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(setq buffer-A (current-buffer))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(setq-local window-configuration-change-hook</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
`((lambda () (message &quo=
t;Hook called"))))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(insert "line1\nline2\n")</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(setq target-marker (point-marker))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(beginning-of-buffer)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(delete-other-windows)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(split-window-right)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(other-window 1)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(switch-to-buffer "buffer-B")</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(with-current-buffer buffer-A</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(goto-char target-marker)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(minibuffer-with-setup-hook</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(lambda ()</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(enlarge-window 5))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(read-string "Please select enter/return key"=
;))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(setq actual-marker (point-marker)))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(cl-assert</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(equal target-marker actual-marker) nil</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(format "Expected %s, actual %s" target-marker actua=
l-marker))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
```</div>
</body>
</html>
--_000_SV0P279MB0442CECC796A20B54473A58DC6D8ASV0P279MB0442NORP_--
bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.Received: (at 79927) by debbugs.gnu.org; 2 Dec 2025 15:27:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 02 10:27:30 2025 Received: from localhost ([127.0.0.1]:60475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vQSHp-0006az-Jk for submit <at> debbugs.gnu.org; Tue, 02 Dec 2025 10:27:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46284) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vQSHl-0006aR-ES for 79927 <at> debbugs.gnu.org; Tue, 02 Dec 2025 10:27:28 -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 <eliz@HIDDEN>) id 1vQSHd-0002AL-Vr; Tue, 02 Dec 2025 10:27:19 -0500 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=NJ/ZcjC4GVPTnp6eqLNJ7bCrRbONA8NfvGSYH3SHFrM=; b=quN7Rhoy9ZaKaWXqW6jL +M7mOfjK8WmOfQ7jzQbZ0eICMi/vOINT2Jcfk7b9fpvUbEuY4njqNZyTBwpkZ9VAv3bh11q6RhNFH M+zf+jLXhXb5UVVCP2uJAfqM0hoQKZUqy9bSxmr4H916oLRxkYl8U8eFQ4UuHiCYGZwY81EaHYN3/ /FXHJFMUM1rlNjxZOcnIncdbp2638/HrmlbNP/EdlIIHR2wGUOM91fDrXJsFj/Fz3gE9EVT1uFHoJ Lx10fnrW/Pc1KsendisV/DO/I4B+CI+GxrYlmmtIa3JIfvr3sIjhfhRPvB4+ZM/msludhPdOXBo1P 0RiNBuxZWh6bGg==; Date: Tue, 02 Dec 2025 17:27:14 +0200 Message-Id: <86seds3nvx.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ignacio Casso San =?iso-8859-1?Q?Rom=E1n?= <ignaciocasso@HIDDEN> In-Reply-To: <SV0P279MB0442252DEC6BCBA711506547C6D8A@HIDDEN> (message from Ignacio Casso San =?iso-8859-1?Q?Rom=E1n?= on Tue, 2 Dec 2025 09:32:59 +0000) Subject: Re: bug#79927: 29.1; Unexpected buffer point movement on redisplay References: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN> <86ms424adq.fsf@HIDDEN> <SV0P279MB0442252DEC6BCBA711506547C6D8A@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79927 Cc: 79927 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ignacio Casso San Román <ignaciocasso@HIDDEN> > CC: "79927 <at> debbugs.gnu.org" <79927 <at> debbugs.gnu.org> > Date: Tue, 2 Dec 2025 09:32:59 +0000 > > > Is the buffer in which I should do the above called below A or B? Or > > is it some other buffer C? > > Ups sorry, your are completely right, I should have started taking about A and B in step 1, not 2. The hook > must be set in buffer A In that case, I did what you intended, and I didn't see the problem. So please describe the steps in more detail, and please also show what you see that indicates a problem. Thanks.
bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.
Received: (at 79927) by debbugs.gnu.org; 2 Dec 2025 09:33:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Dec 02 04:33:09 2025
Received: from localhost ([127.0.0.1]:57427 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vQMkv-000057-A9
for submit <at> debbugs.gnu.org; Tue, 02 Dec 2025 04:33:09 -0500
Received: from mail-norwayeastazolkn190100000.outbound.protection.outlook.com
([2a01:111:f403:d20f::]:23645
helo=OS6P279CU014.outbound.protection.outlook.com)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ignaciocasso@HIDDEN>)
id 1vQMkt-0008WJ-21
for 79927 <at> debbugs.gnu.org; Tue, 02 Dec 2025 04:33:07 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=LvhM/7aE8M5KHbg0jhl3qt6W0yqEKn7MLB3NTxFsJEiCdTwZ0ALf8CmpYkQRizlnOzJkbFD4VV27h3R06JwVsfkxjjwBQyAdGJ9UElqr8Y8un6VwDDbfKxUfdULw97oMDpVVjJvEWrcSpnWL4cOtr3yLzM4vcGByTaRg4X+6ixI6mzmLbnyWMkcoIl9PWXbVfk85FWBtlKYs3xJkHQ9e6qIduEUK7fFwsF2ZtfJAAuQmmogBs97q1pOV6l5WBhDCdgu27axC4MKJ0Cn3eNSlXRTwjKuI0+wxEkqq8prumXviUyd2Ob+91qdOkdrznpa8y8j1phQhQS1rgMUvIitWNg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=WRrkHoDjOTgFRMzK06cr/m1XrJC8fuFGpZjRIoIxK68=;
b=LVwu+QJ+Z3IsvKPU04EIcSPDqNa+LRRCGx0k8NQ2637GmqGUTDY9mXIshGetRFWjEODzN59E+ef4XJmSU5wm1CXicwes2IdWDyOZywKGQF4ST9eJVTpzHMXG7DkD6Y9sZL3NYYsW7jCTHYWLLw3iSs0yAW2WQJ6oeJgPZe4wZiVu07S/dE3Cd3gKx/uIyHrd09Zt9Qrge2s+CTVaf5gQ8/KpSrVH4QHIRFEOvcuxNpsmTGku+kRgXstOntn0YshbHGwLQJqkwBm/WR+AqqzVhdPowVYXMjugSn7lINQIRPuLS3JcPinm1iOSvRy9GE2CmzCln2AyXKGIuBopuI6mJQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=WRrkHoDjOTgFRMzK06cr/m1XrJC8fuFGpZjRIoIxK68=;
b=VkY2eB2DsIDhnpsDmtmtJZVkON0EQjS98Q6KCcbDO3RbFS6Rczancg3+RgUbjRWgQEjozznRSPP9HShsNweUQFiwcxiOSRssPzOpZTFhI+TMtoidIoYzFRRKCUSHCZzqg69q559eSptEzuuS0jfPomOBsPSQVj7Jcm7ePCARjmQIFIli5uj9ok1BNVEAE9jPGeIVcBeXGJdB0iGTmvsfbwKAcy6ygbhcSevPLePKF9kcyoMHAFUXQLS2zKAY3IPao+bcQRnOzzw8/0SYASCY47gAlsVU7LN5NCw/2d8ydduwPwKrDn4fvYCKeJEhvqsiMLcWKkih0ukSPmdykmsxAw==
Received: from SV0P279MB0442.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:19::11)
by SV0P279MB1262.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:36::12) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9366.17; Tue, 2 Dec
2025 09:32:59 +0000
Received: from SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
([fe80::e7dc:921d:1322:a269]) by SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
([fe80::e7dc:921d:1322:a269%7]) with mapi id 15.20.9366.012; Tue, 2 Dec 2025
09:32:59 +0000
From: =?iso-8859-1?Q?Ignacio_Casso_San_Rom=E1n?= <ignaciocasso@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: RE: bug#79927: 29.1; Unexpected buffer point movement on redisplay
Thread-Topic: bug#79927: 29.1; Unexpected buffer point movement on redisplay
Thread-Index: AQHcYrs/ZfHPjlDt8Uazhj06KM3jFrUMwgERgAFUMSQ=
Date: Tue, 2 Dec 2025 09:32:59 +0000
Message-ID: <SV0P279MB0442252DEC6BCBA711506547C6D8A@HIDDEN>
References: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN>
<86ms424adq.fsf@HIDDEN>
In-Reply-To: <86ms424adq.fsf@HIDDEN>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SV0P279MB0442:EE_|SV0P279MB1262:EE_
x-ms-office365-filtering-correlation-id: 7e9f5fd9-5688-4c62-2067-08de3185c896
x-ms-exchange-slblob-mailprops: bJx5BVzHBHuy7zBViG+jqGFVKxs0xfUGIjDPaxBrA+vIOqjyDL1/d9eP5qfmz+zu6XPghD/aZQsmllpb7fWypTn6a70DfQUDpk1j7DSwmMkyIIMs+IfnCCPkCzsRHsWJerb7kAo6pk4pZoZaUUPxU3Xrv9ICQX+bqcoCZdQJ9hxXFmToW6ggpmSPEDZZGJvEMz9iWWmtf6ohQ/wAh28pPI5PuGcbLqoxCrOaNNttGn3+YQ23n6g5fDBdDxzUhR+AF7XWH3red07Vqp6qBtb8W0OoT74wzu8A4WV8w3payJzGiqBcPimkM6VqQo3fAbiCLf2J/XaB4qbnTiz1EHhq6VUJnzDrhxXogG4Ikq5ciCAXwz9K9OYVQvC5NNdriCPsRmeOgJveoUCioV3MnlrYeFY8XJwtHcvbBU3ycGdOnjZSK4g9PT81Ppt8bbqtwu3ML6sChLh+oTdtTtkqeook/DtlJmK0wEKjdZtb0Bud0RmuVdgl9habCTXbntpJTlz7V/J6Gk1h3BRv2n1bhbsd5gyjRSh+cBxpLCEUfpqfXMgiUEI0q4/lCJqa7Us9YlseDll6gJGbYTl/c7uWFikt0k7+qqqWnbp67Jwuh/9+1L2+k+7JKBev/U6+aKMjh6l+q3cXjoR13HKxeywOvYseVpRe/UtesyEK
x-microsoft-antispam: BCL:0;
ARA:14566002|8062599012|15030799006|41001999006|461199028|19110799012|31061999003|8060799015|15080799012|40105399003|52005399003|440099028|3412199025|102099032;
x-microsoft-antispam-message-info: =?iso-8859-1?Q?Sx8It5Ffp5WJw/Fui4Dvz9SwUcc8o1PxVBgz/pWBYqR4n85QEXvES1t2NO?=
=?iso-8859-1?Q?dHwf4CL8zZiY4Y9x+VPvmY6clczkL/VKnLgkipdMDf9e6Yw2SqMVJLe/gy?=
=?iso-8859-1?Q?ZsMuA1p7jSZSAMUHya+WmKWoDHeltE5ZO74pcHGqP32ZSbxggRF2IjEpbN?=
=?iso-8859-1?Q?dvugfQKT1/0unRZKudO9D/2qBY+OJcxMc2bGLALjAcC1+aAy81xkyvWAj8?=
=?iso-8859-1?Q?YhR6A2zgXPiDpmNhJs/qn4PYdSwaV1O8ruWbpMAbktE6GWCw/1K8ubxfEW?=
=?iso-8859-1?Q?H21JvfTxTdmfuDir+XzWmy6hpjtmGmatlf0K3Z4ayQ7z7CDQ8vHrTMir+S?=
=?iso-8859-1?Q?AMIp/s/gFcyKdghZic5XdX96pT6BjlATqZFxSeCnvHa877N+XVZo5TsfaB?=
=?iso-8859-1?Q?LvhRHXy4Izqwc/n57LrFxwDzx39BV5Z+pqVCwCapcylcZWsYzrBc8syPXE?=
=?iso-8859-1?Q?MXBMaDHVhT4/+m65jxU43V2jqqkIyee6ryumijxGMUbCXbvLKlyCmLrhCc?=
=?iso-8859-1?Q?dAZcWsbD5VOX1IImHMXoJsTNxlz38QBnd34pcefU7/H9uaLkWulVwA+SfA?=
=?iso-8859-1?Q?OJtguOL/z8UWyDApynrN9w4+PU64mdi642hYi8NDz3E3xthaFR/+M/oTd2?=
=?iso-8859-1?Q?qyV8H2RxlzVLOlKV8oRrrn60XTF6qujosJtnRRUbZVdbxsIDSwvzBpO2sS?=
=?iso-8859-1?Q?5vtqhiuBt7qcSMPnNFGXdmRwwN3Mhpgp+enOEdXCs5xGsdLFINQNj7ZqD+?=
=?iso-8859-1?Q?ycC8pkhcKMdsbeq3KbN2y8SskRIcgJ4soavynnDyN/lYTL1X5EJXfz+ZI1?=
=?iso-8859-1?Q?6fVqD65PqxA9z8B45UxfSZzg49rc9j1GgMbDAO9pB1cELdIVMeCzUF+rZr?=
=?iso-8859-1?Q?mmmEpnRFExEIn70MICF0B1uoVE+QukbuaI6lS5iGARepDWl9PhmFD+rkWr?=
=?iso-8859-1?Q?0bCenqVTfDeOj2BpwtLYDrgUH6Yszuzial7FtYxCebZQAgdcNOg/YX/oFE?=
=?iso-8859-1?Q?/HTUorFonoEM6kkS2i1iDwXz3m1qK0mNRM+9TTjulqiYuAiw/CtIIP161W?=
=?iso-8859-1?Q?95k0xPBeEZdViRVYLUR0YJu38REvAcd0POdqIOqCjLcqOd3+iJKJtEFbJG?=
=?iso-8859-1?Q?yZbMbcf4WWr4jtirK2MhuSsmK9rcKeWC4y4XTqjtQx7NfW+iUm4QHsaE0c?=
=?iso-8859-1?Q?TZHfYBYZjqAbuOrqvqYcv57H1gkiHzkGt/juavGMjiJJTlCH6UIryRH1eL?=
=?iso-8859-1?Q?gPd/+ZOiEiVfs977ETGpqamLHTIMm6m3etjNOyIS+pynUal6ujaM6QzPG5?=
=?iso-8859-1?Q?tEvR?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?4uBBA/ZSWebsabwn+CWvG3E08ImJN9+3Cqk/6dWN97K1Jrjbq56w0VOI/Q?=
=?iso-8859-1?Q?JeHHFf0VSIAjiWR3DI3C6BeopzHYVn0u+/QkjYMTSn4O11rn5pc8uSXrF6?=
=?iso-8859-1?Q?x8Jf3ODCIvVuAhIfTZatKls+sZCjFszYtDoNpzOADeEptcXFcliQXYmD/O?=
=?iso-8859-1?Q?TZfwWxn7wBrDSogUNhzDCqAAihsTMTbXDyEHe9elFP2EPH899awOCdn3vQ?=
=?iso-8859-1?Q?bUQkJ7Roqco8jLnWU4VAE+n9vtjz+dmd4zX208zJK8KVTysadpDv+6nQb8?=
=?iso-8859-1?Q?3nCwjxDpjLMzXtnFG4+HI18/a669j7qQLixuBRyuEAWQb9JqZksIZN+K12?=
=?iso-8859-1?Q?7m2goVRb1ylqbQeJikZkkIDA9SLELp79FchCRixXjtcrNO345XQQf46d3w?=
=?iso-8859-1?Q?IBfT10AO8GJqOtcWDgxc9IvE6SYv2nOterrPEFkxqnCIglfaLw3mXbm9nX?=
=?iso-8859-1?Q?/EHdMOLQuRSDAURj4C3GBrBN3fQlsTsDYrPd3Oqb+lV+DZsYC3iI68Qy0R?=
=?iso-8859-1?Q?YFzfgCIUxncQ2g+2SiPNHl/byxgs2MyZeSwOhbRsM1L6VW1TrA+fMmkCfZ?=
=?iso-8859-1?Q?i3x3kxlVry/oZkEaK3qk85Z3JsOVQniFc+t/43ienvHmdX+wKZ0o4WVM7B?=
=?iso-8859-1?Q?EcKo21RnWce3VTfettF1cAm6r4dWG0ChxBGwEkEiaeuWjaIQcVyLcypjHK?=
=?iso-8859-1?Q?gxZxtC28O39QttnWlNHuOrhtkQBCugQXg565dRuDPtd5ilxGIup+Cfv/Og?=
=?iso-8859-1?Q?bzQf1WX3jv5LR5yJwqabObLb9/0Nnbua02E9uxnso2KMrfLHPteFq+Hiev?=
=?iso-8859-1?Q?2q+v6oSYCBjwZoMv145DKhVuCEONTjRvTLSwFKmvRJ3T5fkq9yIMmh4+/J?=
=?iso-8859-1?Q?XA7NxUodq77xnqzVXWRkQFCg0dfyBenCOe2RWj6ziE8WgPgu+x52bDFZnK?=
=?iso-8859-1?Q?PCGTy9DBNNptIZkl/liTZPUqp4VLyNj+kIR5I8j84zEbbNri5jBn74X1cP?=
=?iso-8859-1?Q?/4WwMbmgxMuyS/yeNsecrD1rux8q2BNkDFiu8J27ni+LFyD7LZqgECdd+c?=
=?iso-8859-1?Q?OqO+B94UcEqgMhIkm6neLTkvoW6+/kdDKMAnVggsWVSAO3wkEWmsejoU74?=
=?iso-8859-1?Q?O32zXfXTExTmSmOqmve3N2z0H+1pmFTNfvWSLacPtuqGQGDThDBmaqWXPn?=
=?iso-8859-1?Q?AXq9dLRwfuyxfsRZUXBg54fYUMenERSJIcyxdeGruCK4HL7ye7SJt31iAT?=
=?iso-8859-1?Q?9VIQ3F66GeTFNnm2PcHNOtZEm2Na3xBswjpgFGTlg=3D?=
Content-Type: multipart/alternative;
boundary="_000_SV0P279MB0442252DEC6BCBA711506547C6D8ASV0P279MB0442NORP_"
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-7719-20-msonline-outlook-9812d.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e9f5fd9-5688-4c62-2067-08de3185c896
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2025 09:32:59.8420 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SV0P279MB1262
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79927
Cc: "79927 <at> debbugs.gnu.org" <79927 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--_000_SV0P279MB0442252DEC6BCBA711506547C6D8ASV0P279MB0442NORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
> Is the buffer in which I should do the above called below A or B? Or
> is it some other buffer C?
Ups sorry, your are completely right, I should have started taking about A =
and B in step 1, not 2. The hook must be set in buffer A
--_000_SV0P279MB0442252DEC6BCBA711506547C6D8ASV0P279MB0442NORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
> <span style=3D"font-size: 11pt;">Is the buffer in which I should do th=
e above called below A or B? Or<br>
> is it some other buffer C?<br>
<br>
</span></div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 11pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Ups sorry, your are completely right, I should have started taking about A =
and B in step 1, not 2. The hook must be set in buffer A </div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 11pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
</body>
</html>
--_000_SV0P279MB0442252DEC6BCBA711506547C6D8ASV0P279MB0442NORP_--
bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.Received: (at 79927) by debbugs.gnu.org; 1 Dec 2025 13:09:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 01 08:09:37 2025 Received: from localhost ([127.0.0.1]:48164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vQ3er-0000w1-H8 for submit <at> debbugs.gnu.org; Mon, 01 Dec 2025 08:09:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47758) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vQ3ep-0000vJ-Gn for 79927 <at> debbugs.gnu.org; Mon, 01 Dec 2025 08:09:36 -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 <eliz@HIDDEN>) id 1vQ3ek-0006OI-3H; Mon, 01 Dec 2025 08:09:30 -0500 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=gRUfaCWLl34xijLO1l98dAbVTyblDcTytbEx5eXrhYc=; b=Aoobmz4xqZEC5YIBtgTy IRriGxtOOfAHk3vBirOYVdgvuNf1dGBoeud39Qr6lPapmEBPdPbbheKzOCRgjE3MnfwCFQkiVGZ/H DFGkD5h1thqpa6RwyA0JRRfskr6bJ1pu4bKVGlHINZhwB7hwvLUc2q0NUz6WS+RjJi1fUCTwXqaUy BqT7v8nGs/dkKuCr1FF0TMvWSitiPJ0mUE3re2tBLtuRlWlomgTLSFRBBITxCzCYsjXFUOmjQ3P1o GEoySDOhqhNwXHQhIrv6lhVZkKPEDcpJj5yADCiiTr3T4Jucvin4W60PSMDxezzYwqMd2TDkgYjNh QBFY3mrZ3gNdBw==; Date: Mon, 01 Dec 2025 15:09:05 +0200 Message-Id: <86ms424adq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ignacio Casso San =?iso-8859-1?Q?Rom=E1n?= <ignaciocasso@HIDDEN> In-Reply-To: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN> (message from Ignacio Casso San =?iso-8859-1?Q?Rom=E1n?= on Mon, 1 Dec 2025 12:14:27 +0000) Subject: Re: bug#79927: 29.1; Unexpected buffer point movement on redisplay References: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79927 Cc: 79927 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ignacio Casso San Román <ignaciocasso@HIDDEN> > Date: Mon, 1 Dec 2025 12:14:27 +0000 > > 1) Set this local hook in some buffer > > ``` > (defun my-dummy-hook () > (message "Hook called")) > > (setq-local window-configuration-change-hook '(my-dummy-hook)) > ``` > > In my case this hook was being set by flycheck-mode, which is enabled > by default in most buffers with `global-flycheck-mode` Is the buffer in which I should do the above called below A or B? Or is it some other buffer C? > 2) Run this in some non-empty buffer A with point somewhere in the > buffer that is not the beginning > > ``` > (setq my-buffer (current-buffer)) > (setq my-marker (point-marker)) > (beginning-of-buffer) > > ``` > > 3) Split the frame in two windows, leave buffer A in one, and > select the other, showing a different buffer B > > 4) Run in that other window > > ``` > (with-current-buffer my-buffer > (goto-char my-marker) > (minibuffer-with-setup-hook > (lambda () > (enlarge-window 5)) > (read-string "Please select enter/return key")) > (message "Point: %s. Original marker: %s" (point) my-marker)) > > ``` > > The first two lines are more or less equivalent to > `org-with-point-at`, and the others emulate a completing-read with one > of the modern packages which will most likely change the size of the > minibuffer. If you read the message output by that expression, you can > see that the point is 1, corresponding to `beginning-of-buffer`, and > not the one corresponding to the marker that was saved. This won't > happen if the target buffer is not visible, or if it's in the selected > window. I don't think I can reproduce the problem you are seeing. I tried both Emacs 29.1 and the current emacs-30 release branch, and in both cases I see in *Messages* after running the recipe Point: 176824. Original marker: #<marker at 176824 in dispnew.c> But maybe I didn't run the recipe as you intended, see the question above. It is not very clear what to type in which buffer/window and what you see as resupt.
bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 1 Dec 2025 12:14:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 01 07:14:46 2025
Received: from localhost ([127.0.0.1]:47597 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vQ2nl-0002uL-HE
for submit <at> debbugs.gnu.org; Mon, 01 Dec 2025 07:14:46 -0500
Received: from lists.gnu.org ([2001:470:142::17]:35464)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ignaciocasso@HIDDEN>)
id 1vQ2ng-0002u1-Sc
for submit <at> debbugs.gnu.org; Mon, 01 Dec 2025 07:14:43 -0500
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 <ignaciocasso@HIDDEN>)
id 1vQ2nb-0000XZ-F4
for bug-gnu-emacs@HIDDEN; Mon, 01 Dec 2025 07:14:35 -0500
Received: from mail-norwayeastazolkn190120002.outbound.protection.outlook.com
([2a01:111:f403:d20f::2] helo=OLAP279CU001.outbound.protection.outlook.com)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ignaciocasso@HIDDEN>)
id 1vQ2nX-0005zW-NR
for bug-gnu-emacs@HIDDEN; Mon, 01 Dec 2025 07:14:35 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=TqLXj6vzDFwjI3fjDcw5R1hJfK6kd6Md3vzBRxICJUBBfttQrZ38FY1+VAQVACupodHJP33fUUwDUnDnCTuwfOy3KZufMCt92CLk/S8C7remq6fcSZ7zz7WggDmTiTmK+MEJW0QunO90nKOFDWego4Cx9+CpPE7WiTO3AKDvpwcDXwEwoMN9QEekQPP/uARtzQbI4pb3TTiogNjRoF2SkasErp1zAHSXuD1gMIqBPf+frnmb3A+YC5xyHBOmXUwvT11pLJXVnuaUtoUEtO1r7mVtPbLnYTPEYIoAekmDJe7a6xFLlA5dLyzLFsT2tiRlteuh0N0WlMC0WdbACQv4ew==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=pd/6+eAPV5h6BoAMOU37FdWY8nE52p9KEqrTQrNm1Ew=;
b=zAW8bfxuaqVrOjBwpsnsYANzDfQ2dWRbUjdDPQgQdZ4Y32ulxqfrfA4/UXQtdxOTVppRpYXxnBzSRVc2GhhEtc3ebDYsIRVmW7QxNtulaM8dFE15T3hsDS68Cyl/q7S1K1qwKVrTxJgDUrI+zYvrEBX4t1bfqjscEl2EeLuK3eTg8aO7l4NPxmXQby7vdGT6M1Uv8TD33yBhdsfm4AydFfYOV4j3hE3Nbdb3OzSUic13nAItywCKLXV/5dn1WYqKPsX8OaQ+xJsi+XW/DWNiTnvTseync4f9Ng74isQ2gP2Zro5U6owL2XgALMbdClBK/Fz9lbPuSHx94BRjlBgFBQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=pd/6+eAPV5h6BoAMOU37FdWY8nE52p9KEqrTQrNm1Ew=;
b=cFz6OYz+BdYAYCKpWtpjWaWWVzSjCtma8sERmFr5bH5Go1KLWOJT4hQNpTwauq4RZtMhe+29KD/4dm9kr+p006NM2C9QiBaqv5VbT57kC8eoWI0+3AE4h3Bn2rpaYK0dW7Z5xccEH1/BJuVSBpkSIcraNIk/FOCH9M8Vdvm3a78aZVWuadkLB0xQR92mFrXeN8W/zqNF+iJve/n6wkontB6RX7qgzxUsHP9VfGB3EonWUeJW4TFh66+g7nSTyHQUhgeJ/5KKwZNzU+tZVeObi+zkDzps6ri1i/jVgIBgZ4sUXbX5M58jlx2EKun4esxfAOiGmcOqnQhTcSDYV8BVNw==
Received: from SV0P279MB0442.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:19::11)
by SVAP279MB0029.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:7::11) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9366.17; Mon, 1 Dec
2025 12:14:27 +0000
Received: from SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
([fe80::e7dc:921d:1322:a269]) by SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
([fe80::e7dc:921d:1322:a269%7]) with mapi id 15.20.9366.012; Mon, 1 Dec 2025
12:14:27 +0000
From: =?iso-8859-1?Q?Ignacio_Casso_San_Rom=E1n?= <ignaciocasso@HIDDEN>
To: "bug-gnu-emacs@HIDDEN" <bug-gnu-emacs@HIDDEN>
Subject: 29.1; Unexpected buffer point movement on redisplay
Thread-Topic: 29.1; Unexpected buffer point movement on redisplay
Thread-Index: AQHcYrs/ZfHPjlDt8Uazhj06KM3jFg==
Date: Mon, 1 Dec 2025 12:14:27 +0000
Message-ID: <SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBA@HIDDEN>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SV0P279MB0442:EE_|SVAP279MB0029:EE_
x-ms-office365-filtering-correlation-id: 28b69d20-7596-4321-4e69-08de30d32c51
x-ms-exchange-slblob-mailprops: Vs63Iqe4sQkBP5bXNS6lZgUHop5/RlQyYTR6De/d8GlY+z2STU0dBNfcI6UD3OVPGem+n3PnDxvbgPugEzbJ/1HvlZ04Cwfy13WguElj/xiaMGXO6gQXk8rPwx67fuGxl2n7CZG3w5r0P/pNP/9HDRWUsymAUfkGk3WLimqb/fBdf+Zr+qB6fVrXLMCUiM7YNL4WWiExil+S6ILIbO/tw4aTRZl3yoNDQa9EiBmW9L1s31r5EFW4KCXHJ+ZY9LYXSA7SylDwKMkps+crdQjgoRk47x4htaOWYMeK/L7crBRRw+7C6/xiHrNfroX6pRJ1WpKAGMheO5C/fAJ+RlqrKoQZGQdFXFmelri7J7EfutWMwd+insKvL1Z9cA147k59xxTZohujLTT67z5GqDxXoHQqUXPxNcdJIlYlevd0+w2mhgrWMT44ptzWA9M414431xkhr8/X6J3aaHQyjNobX5DuF82eLodevaNNWIoEo7PvsOhyA60YfCsee/L7oT/UsG48cG5uAeSAxA6pKozNFk9HGk6h4tjQhRXoDtHb2wOX42ENxiO/nSCafdbJMIsZgtFKIS6B/JrplctzWZdIl7fmhuPnKGaGt/lOE3SN/b7V6rOf5+FhmAPnXXSxGSfA6ncKsa/PtnzRTNhZoU9aTe3X75k5PJE0kcvdGlN1d1qN915sViVRQ6aK0e7Dv9ljIDp6alOMNyiYaxZKwjoVuZphvqeWahMIbcE4hzeoScE=
x-microsoft-antispam: BCL:0;
ARA:14566002|12121999013|8060799015|41001999006|461199028|15030799006|15080799012|8062599012|19110799012|31061999003|39105399006|56899033|40105399003|440099028|3412199025|102099032;
x-microsoft-antispam-message-info: =?iso-8859-1?Q?ODqxVuS0piButJfSdBtLFtAsK3WctZbwZRCRLKaFZwRWUgEZWKBrvL8+88?=
=?iso-8859-1?Q?JCVvi20m2Ri4J/tuRL3xHKaa/1Aa/zFeoMo/rkCpkxAAZrJxky/O4yHvb7?=
=?iso-8859-1?Q?Bdkba4qIPqK++aXFJFD0vLUYD4VkARyg/SGVKFrphP5jFlRgBTTtWKB12G?=
=?iso-8859-1?Q?S143TOFAaEIBik6qnsr4K6GoKgavU7iHKF3wdJk2kQnomIgtE0+hT2JQVU?=
=?iso-8859-1?Q?z85CYjbBeXzFRFc8Ghb0PIGnZxhoUkbz5WjRMa7wXpRKKboXCA6uWiyEf9?=
=?iso-8859-1?Q?Wf5vhfgHgHIAOVYsRcosxNvHgjs3Ui2xHpfx9HD7PhhaUJ2dnHnR0KP12H?=
=?iso-8859-1?Q?hCbsSOWTjCpk4DjArcTT3mMmvq/dh38W8PDRcRSkBy2hs6gtuIXB9b+F2v?=
=?iso-8859-1?Q?JzhQpSRioiMVrrEjUKKJ8b8IiGhHms3KP2/x7MMm6+hFEL+tfRJi3+mQPK?=
=?iso-8859-1?Q?eY2MbjMFDaW1DkvafD3tC2+pHJ+ipqDKtGajeQIvJgsk1Gq9AW5pXkhA5g?=
=?iso-8859-1?Q?+oQu7aLk30WvJ0CrEGVDBposuBGGTcfOhs5+WTDjl39IURnemXtXecWMdl?=
=?iso-8859-1?Q?tEwZdyg179+02XAcGUzAqh64izmpCkTbz/7c0KUFboAdqsFMi/o3WCmlx9?=
=?iso-8859-1?Q?8+rktebVuiYuH9i+KyVgrOzE6M7MBsVAP1AW8c/vk9rck6xG6j2ZpZZ9sM?=
=?iso-8859-1?Q?z15TRMUqW6RdyNkbSwuKvlYiWwzYL+NkFy4ZtZn4sBjvZAG35fHZBWYa1y?=
=?iso-8859-1?Q?ZlZJsKYWi4n46oL7QT3Nb9OpDVrKfhO+mlU/2lDhYWF8kmwQ1eVqo1PF7L?=
=?iso-8859-1?Q?kukn1pTvrCtl9IyubAY+doOjuGS9RAyr4Gc6IGONWG7gD8Ww5erP3GMIla?=
=?iso-8859-1?Q?Ba2q3DZcRLbsZof4P3fQQc5bYi0mq1BS8qEaeTRjQ8r1YLtoEUKeNBUKDQ?=
=?iso-8859-1?Q?2yrION7E01lFdMFQ4hOAoIFUSPGKmuv+IeyqffICnzu4k5SHf/gLqf1PCE?=
=?iso-8859-1?Q?OL3+bPCHqdCywxrSLbwZxCLfx4hihqgrNNH3Zk/wt6C785Mqnsnit9DNSA?=
=?iso-8859-1?Q?5Aqz1pboXFv3ev3WIjIQDmrudz26cPT4kY5U7e8c155k2092aAHVGF3V8M?=
=?iso-8859-1?Q?5EXyvd5vrq7icSxnPbpm0f8bhsmoVusFEX0xefUtSIvPkCag4ZJSCwCnGS?=
=?iso-8859-1?Q?IFzo5BcvJAhNhhSK4hkpeAq1JmvyEfBcAg9XkOENHArhL+Rw6Xqcn4+5yh?=
=?iso-8859-1?Q?6eJQBQu/AHBl+9uP+6MplotdmCcbcLWobOngJR0VLyJuIKpvYOns7nfzyf?=
=?iso-8859-1?Q?xd1cEL9P101n0AHYRcwjxAgrbQ=3D=3D?=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?wJPCnYBC9tcN269TXj6KL2V0Gi7Pjv7ztzJZuuwsXc1KfYIHlheMIjWYB5?=
=?iso-8859-1?Q?f+8oGLfdQuE5ixfZDXtgf6Cm2G5yAq87cGmFwgkN+fzKNjY2U+SX3VvFbA?=
=?iso-8859-1?Q?7+YqIc7INe0ed9PA+3MWfFYa1Y0GVf7zCtF59GPNZD55AxxsrviezuIAao?=
=?iso-8859-1?Q?0lQFjW403lOvNvf1MFQLQz2R3qEqVSAnb6c7Bji1YR/RHR1DQLZwXyntDY?=
=?iso-8859-1?Q?3NhiMzwyz7vg5yQlCIRs3V7SGLFupCy9bH1dtrK0dmB5sCVhGmMWQ8fYgX?=
=?iso-8859-1?Q?6PRW6hWmWJk72wwJuP48TXdCzYkcgZlKC5bw+ESVYHzXwNU16/QTUoehu1?=
=?iso-8859-1?Q?pwwS93Kg3kS68VF8nSR/FcgkKMK4/pe3cPnr7zX3RrDtfX1cplVUfBVvcb?=
=?iso-8859-1?Q?uU+qfsY32/eRlrtxBCKhjqbFY4dud76fbH2V4e457fRD9IsKSOk3jw+G2g?=
=?iso-8859-1?Q?F4PRWHD41/unGI78mO1PdgogVIVQELdlkUwjp75crgfIjsQ+7TJAOOZw1z?=
=?iso-8859-1?Q?Bg9n8Sn/C0V5euIbrWVD0FusOJw743YhsAFPcBm7/vpVyHfqdiMsstJE1V?=
=?iso-8859-1?Q?+TSXkOcKZEaGJDfmSLyUB6ERbnNFMr3fCnYnYw0PuCtfD/OPLZrRFE11XT?=
=?iso-8859-1?Q?s5RhB5+0qg9UWemWonHCE6VN0iQyEs4Wc89Tf9Oh8iE6O8J5ACVpB9f09N?=
=?iso-8859-1?Q?22EQ4iIg0hlKvbBfjOcVb8FnzSrJK7XzEV/19+kKgRGaqaP+ksEB8EfH5Z?=
=?iso-8859-1?Q?oARXg++RzvnCz7rFef+fXWY8AwCyV1bRoIl48GDmRRw8NPuqJYFpU1eRzH?=
=?iso-8859-1?Q?PI/9xAsULCGniy5Y8jQdIW9iXqt2auUwVCukJFd8W1ubPROT+HSwcaIMxu?=
=?iso-8859-1?Q?YTfEWo+9NkuB9sCUEz46Co+xmeLWddNRoRDKKM3xRH6eYMo4/YMemvUF93?=
=?iso-8859-1?Q?zebdvbuoWNkCJnqmvM3KyV4QBcwLQX0k0+xYB0c2vmHLoz+S/lQTEF9m+3?=
=?iso-8859-1?Q?WqQdlzctUMKlVXJg/tvzutVQOf8WWR07zb9u9G9sgOWa0JS19nl9JWX94H?=
=?iso-8859-1?Q?bC0j/BPcdQHx5ttt92XJRL751+jIAyG/OqKKaQvZr/70/S31kbWW4Oh4PF?=
=?iso-8859-1?Q?MqLNox/TIVDOU8YuvH7KuJvoGcBYgmtzPnKiejvnMZzIY1kfbcgtKBeE89?=
=?iso-8859-1?Q?h+dy6zq2EHkIcOYFhapT94R2E2TGgv/wXq+7bgkgET6mWW2u9szgAdBJzN?=
=?iso-8859-1?Q?fdlF2uZEYkBVoKohrmw+gQjEfOLgQBoxw6ix+BYV8=3D?=
Content-Type: multipart/alternative;
boundary="_000_SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBASV0P279MB0442NORP_"
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-7719-20-msonline-outlook-9812d.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SV0P279MB0442.NORP279.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 28b69d20-7596-4321-4e69-08de30d32c51
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2025 12:14:27.2923 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SVAP279MB0029
Received-SPF: pass client-ip=2a01:111:f403:d20f::2;
envelope-from=ignaciocasso@HIDDEN;
helo=OLAP279CU001.outbound.protection.outlook.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.1 (/)
--_000_SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBASV0P279MB0442NORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi all!
I wanted to write a command which could modify an Org entry from the
corresponding agenda item, and for that I tried to use
`(org-with-point-at (org-get-at-bol 'org-hd-marker) <my-code>)`, which
in theory executes some code with the buffer and point temporarily
changed to those corresponding to that Org entry. But I started
noticing that sometimes it did not work and it tried to edit instead
the entry that was originally at point in the Org buffer. After some
debugging I confirmed that this happened if and only if the original
Org buffer was in a non-selected window (e.g., if the agenda had been
invoked from that buffer).
After some debugging investigation I identified the issue, and have
minimum reproduction steps for it, with emacs -Q, and no longer
coupled with Org mode
1) Set this local hook in some buffer
```
(defun my-dummy-hook ()
(message "Hook called"))
(setq-local window-configuration-change-hook '(my-dummy-hook))
```
In my case this hook was being set by flycheck-mode, which is enabled
by default in most buffers with `global-flycheck-mode`
2) Run this in some non-empty buffer A with point somewhere in the
buffer that is not the beginning
```
(setq my-buffer (current-buffer))
(setq my-marker (point-marker))
(beginning-of-buffer)
```
3) Split the frame in two windows, leave buffer A in one, and
select the other, showing a different buffer B
4) Run in that other window
```
(with-current-buffer my-buffer
(goto-char my-marker)
(minibuffer-with-setup-hook
(lambda ()
(enlarge-window 5))
(read-string "Please select enter/return key"))
(message "Point: %s. Original marker: %s" (point) my-marker))
```
The first two lines are more or less equivalent to
`org-with-point-at`, and the others emulate a completing-read with one
of the modern packages which will most likely change the size of the
minibuffer. If you read the message output by that expression, you can
see that the point is 1, corresponding to `beginning-of-buffer`, and
not the one corresponding to the marker that was saved. This won't
happen if the target buffer is not visible, or if it's in the selected
window.
The problem is that as the documentation of
`window-configuration-change-hook` says, "Functions specified
buffer-locally are called for each window showing the corresponding
buffer if at least one window on that frame has been added, deleted or
changed its buffer or its total or body size since the last redisplay.
Each call is performed with the window showing the buffer temporarily
selected."
And when a window is selected, the buffer point is reset to the value
of that window point
So if this hook is set locally and the window size is modified (which
usually happens with most minibuffer completion packages, in which the
minibuffer area grows and steals screen from the other buffers, to
later give it back), the window is selected again temporarily, and
the buffer and window points are re-synced
For me this is a bug overall, even if each individual pice might make
sense on its own. I guess there is a reason for the hook to work that
way, so the bug is probably not there. Minibuffer completion changing
the size of other windows is also completely legit. Any buffer having
that hook set locally should be valid too. And a user should be able
to use `with-current-buffer` + `goto-char` + `completing-read` without
having to worry about something like this.
So what do you think, is this a bug, or a limitation? And where should
it be fixed if it's the former, or documented if it's the later? I can
think of three possible solutions IMO, none of which is ideal:
- Every function that tries to execute arbitrary code at some
particular buffer and point should take this possibility into
account and protect against it, i.e., this should be fixed in
org-mode for my case. A solution that works and doesn't have any
undesired side-effect as far as I know is to clone the buffer
instead with `clone-indirect-buffer`, and work in the clone
- Every minibuffer completion package or any other function that
modifies the size of other windows should take this into account and
restore the point if it has changed
- Emacs core itself redisplay logic should be revisited to take this
into account and try to detect this situation when running the hook
Please let me know what you think. I can submit patches or update the
documentation for whatever solution we decide (although if it involves
touching C code, it's probably better that someone else does)
Best regards!
P.D: There is something that I haven't still quite figured out because
sometimes the issue happens even if the window size hasn't been
apparently changed. For example, I tried to check whether using
`debug-on-entry` could cause the the same issue, as it creates and
deletes a window which might make the window change. It turns out the
debug window only steals screen from the selected window, so the
non-selected window doesn't change apparently, but still that's enough
to cause the issue too. Also, at some point I created a function to
reproduce the issue, which didn't touch the minibuffer and did
(redisplay t) instead. If the function was copied in the other window
and evaluated with C-x C-e (eval-last-sexp), the issue was not
reproduced, but if it was run through M-: (eval-expression), it was
reproduced. Anyway, changing the minibuffer size consistenly
reproduces the issue, so that's what I used to report the bug, but
leaving this information here in case it's useful for someone
-------------------------------------------------------
In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
cairo version 1.18.0) of 2025-10-14 built on
ignacio-ThinkPad-P14s-Gen-2i
Repository revision: a9b28224af0f73d1fe0f422e9b318c5b91af889b
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Ubuntu 24.04.3 LTS
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM
GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=3Dibus
locale-coding-system: utf-8-unix
--_000_SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBASV0P279MB0442NORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi all!</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
I wanted to write a command which could modify an Org entry from the</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
corresponding agenda item, and for that I tried to use</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
`(org-with-point-at (org-get-at-bol 'org-hd-marker) <my-code>)`, whic=
h</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
in theory executes some code with the buffer and point temporarily</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
changed to those corresponding to that Org entry. But I started</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
noticing that sometimes it did not work and it tried to edit instead</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
the entry that was originally at point in the Org buffer. After some</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
debugging I confirmed that this happened if and only if the original</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Org buffer was in a non-selected window (e.g., if the agenda had been</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
invoked from that buffer).</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
After some debugging investigation I identified the issue, and have</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
minimum reproduction steps for it, with emacs -Q, and no longer</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
coupled with Org mode</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
1) Set this local hook in some buffer</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
```</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(defun my-dummy-hook ()</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(message "Hook called"))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(setq-local window-configuration-change-hook '(my-dummy-hook))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
```</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
In my case this hook was being set by flycheck-mode, which is enabled</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
by default in most buffers with `global-flycheck-mode`</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
2) Run this in some non-empty buffer A with point somewhere in the</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
buffer that is not the beginning</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
```</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(setq my-buffer (current-buffer))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(setq my-marker (point-marker))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(beginning-of-buffer)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
```</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
3) Split the frame in two windows, leave buffer A in one, and</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
select the other, showing a different buffer B</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
4) Run in that other window</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
```</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(with-current-buffer my-buffer</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(goto-char my-marker)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(minibuffer-with-setup-hook</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(lambda ()</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(enlarge-window 5))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(read-string "Please select enter/return key"))</di=
v>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(message "Point: %s. Original marker: %s" (point) my-marke=
r))</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
```</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
The first two lines are more or less equivalent to</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
`org-with-point-at`, and the others emulate a completing-read with one</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
of the modern packages which will most likely change the size of the</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
minibuffer. If you read the message output by that expression, you can</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
see that the point is 1, corresponding to `beginning-of-buffer`, and</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
not the one corresponding to the marker that was saved. This won't</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
happen if the target buffer is not visible, or if it's in the selected</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
window.</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
The problem is that as the documentation of</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
`window-configuration-change-hook` says, "Functions specified</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
buffer-locally are called for each window showing the corresponding</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
buffer if at least one window on that frame has been added, deleted or</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
changed its buffer or its total or body size since the last redisplay.</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Each call is performed with the window showing the buffer temporarily</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
selected."</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
And when a window is selected, the buffer point is reset to the value</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
of that window point</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
So if this hook is set locally and the window size is modified (which</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
usually happens with most minibuffer completion packages, in which the</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
minibuffer area grows and steals screen from the other buffers, to</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
later give it back), the window is selected again temporarily, and</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
the buffer and window points are re-synced</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
For me this is a bug overall, even if each individual pice might make</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
sense on its own. I guess there is a reason for the hook to work that</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
way, so the bug is probably not there. Minibuffer completion changing</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
the size of other windows is also completely legit. Any buffer having</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
that hook set locally should be valid too. And a user should be able</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
to use `with-current-buffer` + `goto-char` + `completing-read` without</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
having to worry about something like this.</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
So what do you think, is this a bug, or a limitation? And where should</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
it be fixed if it's the former, or documented if it's the later? I can</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
think of three possible solutions IMO, none of which is ideal:</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
- Every function that tries to execute arbitrary code at some</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
particular buffer and point should take this possibility into</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
account and protect against it, i.e., this should be fixed in</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
org-mode for my case. A solution that works and doesn't have any</di=
v>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
undesired side-effect as far as I know is to clone the buffer</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
instead with `clone-indirect-buffer`, and work in the clone</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
- Every minibuffer completion package or any other function that</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
modifies the size of other windows should take this into account and=
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
restore the point if it has changed</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
- Emacs core itself redisplay logic should be revisited to take this</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
into account and try to detect this situation when running the hook<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Please let me know what you think. I can submit patches or update the</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
documentation for whatever solution we decide (although if it involves</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
touching C code, it's probably better that someone else does)</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Best regards!</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
P.D: There is something that I haven't still quite figured out because</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
sometimes the issue happens even if the window size hasn't been</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
apparently changed. For example, I tried to check whether using</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
`debug-on-entry` could cause the the same issue, as it creates and</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
deletes a window which might make the window change. It turns out the</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
debug window only steals screen from the selected window, so the</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
non-selected window doesn't change apparently, but still that's enough</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
to cause the issue too. Also, at some point I created a function to</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
reproduce the issue, which didn't touch the minibuffer and did</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
(redisplay t) instead. If the function was copied in the other window</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
and evaluated with C-x C-e (eval-last-sexp), the issue was not</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
reproduced, but if it was run through M-: (eval-expression), it was</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
reproduced. Anyway, changing the minibuffer size consistenly</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
reproduces the issue, so that's what I used to report the bug, but</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
leaving this information here in case it's useful for someone</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
-------------------------------------------------------</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
cairo version 1.18.0) of 2025-10-14 built on</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
ignacio-ThinkPad-P14s-Gen-2i</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Repository revision: a9b28224af0f73d1fe0f422e9b318c5b91af889b</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Repository branch: HEAD</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011<=
/div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
System Description: Ubuntu 24.04.3 LTS</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Configured features:</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND</d=
iv>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM</div=
>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
GTK3 ZLIB</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
<br>
</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
Important settings:</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
value of $LANG: en_US.UTF-8</div>
<div style=3D"font-family: "Calibri", "Helvetica", sans=
-serif; font-size: 12pt; color: rgb(0, 0, 0);" class=3D"elementToProof">
value of $XMODIFIERS: @im=3Dibus</div>
<div class=3D"elementToProof"><span style=3D"font-family: "Calibri&quo=
t;, "Helvetica", sans-serif; font-size: 12pt; color: rgb(0, 0, 0)=
;"> locale-coding-system: utf-8-unix</span><br>
</div>
</body>
</html>
--_000_SV0P279MB0442DC9C8ABA3A6C08D8E85EC6DBASV0P279MB0442NORP_--
Ignacio Casso San Román <ignaciocasso@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#79927; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.