Received: (at 76186) by debbugs.gnu.org; 15 Mar 2025 15:17:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 15 11:17:43 2025 Received: from localhost ([127.0.0.1]:43134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ttTGg-00079P-Qp for submit <at> debbugs.gnu.org; Sat, 15 Mar 2025 11:17:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56020) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1ttTGe-00078Z-10 for 76186 <at> debbugs.gnu.org; Sat, 15 Mar 2025 11:17:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1ttTGX-0001qV-Pf; Sat, 15 Mar 2025 11:17:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=qHCqHes0ujdsjf+zJQa+xD9qUfxZzMHOrHNcDO+ehvo=; b=THxW+stsqTvS /VoKZHp0oyua+J+iAZf4LeEP7oSSDbuL9/xO/53VMUs51UskVys7GyN1Vxf6FcZrG9zkk6ORRHRRT EK3ahO/GZNv5OlZPk1GvhqIhSPE764UDEXGLQk5m8c/PV0v2zmBSZDVx0RttP1NWSy+Uz8IZWyqrS YfXQVlWL43KlJf+eOIi4MmqRRufPeBB7gTYVuTYTxbkSsgEMZW97vB23ZbjZWMwlhXXNW66K4bkHd AGuFHT4/dY+XPXvLVOvqNuKpDNOV3CEmmhxreN3FEio4qMysCdBi0mLj5CQWizLOowxCC9FvodsoZ gas0NmOHG/pVsz4eVQiwzQ==; Date: Sat, 15 Mar 2025 17:17:30 +0200 Message-Id: <867c4qwcfp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Markus Triska <triska@HIDDEN> In-Reply-To: <87a59m1idx.fsf@HIDDEN> (message from Markus Triska on Sat, 15 Mar 2025 15:24:42 +0100) Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN> <86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN> <8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN> <86wmdihy74.fsf@HIDDEN> <87seo5adv9.fsf@HIDDEN> <86a5adi1o4.fsf@HIDDEN> <87seo2qb2w.fsf@HIDDEN> <86cyezomc8.fsf@HIDDEN> <86bju2y2k0.fsf@HIDDEN> <87h63ur0ry.fsf@HIDDEN> <86ikoawjw2.fsf@HIDDEN> <87a59m1idx.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76186 Cc: 76186 <at> debbugs.gnu.org, stephen.berman@HIDDEN 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: Markus Triska <triska@HIDDEN> > Cc: stephen.berman@HIDDEN, 76186 <at> debbugs.gnu.org > Date: Sat, 15 Mar 2025 15:24:42 +0100 > > On the other hand, it works reliably in your setup Or I've been just lucky and didn't bump into the situation where the problem happens. > Would it help if we find a way to give you access to a system that > exhibits the issue? Maybe via a virtual machine that can be run in > an emulator, or via SSH access? It is impossible for me to debug problems with GUI display remotely. And the problem is extremely unlikely to happen in a -nw session. But if you can reproduce it in "emacs -Q -nw", with a recipe that doesn't require hundreds of iterations before it happens, do tell.
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 15 Mar 2025 14:24:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 15 10:24:51 2025 Received: from localhost ([127.0.0.1]:43046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ttSRW-0000c1-I0 for submit <at> debbugs.gnu.org; Sat, 15 Mar 2025 10:24:51 -0400 Received: from [78.47.144.35] (port=44750 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <triska@HIDDEN>) id 1ttSRQ-0000bV-FP for 76186 <at> debbugs.gnu.org; Sat, 15 Mar 2025 10:24:46 -0400 Received: by metalevel.at (Postfix, from userid 1000) id E37149C796; Sat, 15 Mar 2025 15:24:42 +0100 (CET) From: Markus Triska <triska@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN> <86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN> <8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN> <86wmdihy74.fsf@HIDDEN> <87seo5adv9.fsf@HIDDEN> <86a5adi1o4.fsf@HIDDEN> <87seo2qb2w.fsf@HIDDEN> <86cyezomc8.fsf@HIDDEN> <86bju2y2k0.fsf@HIDDEN> <87h63ur0ry.fsf@HIDDEN> <86ikoawjw2.fsf@HIDDEN> Date: Sat, 15 Mar 2025 15:24:42 +0100 In-Reply-To: <86ikoawjw2.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Mar 2025 14:36:29 +0200") Message-ID: <87a59m1idx.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > I thought I explained why this cannot be done as reliably as you > expect it to be. On the other hand, it works reliably in your setup, so there are circumstances in which this does work reliably. Would it help if we find a way to give you access to a system that exhibits the issue? [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in bl.score.senderscore.com] 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in sa-trusted.bondedsender.org] 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 76186 Cc: 76186 <at> debbugs.gnu.org, stephen.berman@HIDDEN 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.3 (/) Eli Zaretskii <eliz@HIDDEN> writes: > I thought I explained why this cannot be done as reliably as you > expect it to be. On the other hand, it works reliably in your setup, so there are circumstances in which this does work reliably. Would it help if we find a way to give you access to a system that exhibits the issue? Maybe via a virtual machine that can be run in an emulator, or via SSH access? Thank you and all the best, Markus
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 15 Mar 2025 12:36:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 15 08:36:40 2025 Received: from localhost ([127.0.0.1]:39649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ttQkq-0007qc-2Y for submit <at> debbugs.gnu.org; Sat, 15 Mar 2025 08:36:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37206) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1ttQko-0007qN-2X for 76186 <at> debbugs.gnu.org; Sat, 15 Mar 2025 08:36:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1ttQkh-0000Q6-Um; Sat, 15 Mar 2025 08:36:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=OmLG8Bma0E3VUudZBMBxpJ1RgkXN2htRMUHUyXP9ViY=; b=g6Ndd26jF4iN aj08RF8k7OTIjQ7MxsLgH2rGLwBnWb3hkEyIjizIOfOEAF9c6AJj79bRNd5yBrbrTEwm/rt17zR26 ssDWcpgH44PbDqhf9wIzTzadY1OEvALZu3xAVkCDi0rUmTqz8SCi/Ovaqy1HtVBPGm9e1ABwTl4Qb 2wsBW6ISZ9kz/y7m60X6GIuUxfa65YGZQsCgHyfrM3DNfjkmbREslbhuXQCKwT03aSSNvxPMYxscR AV23D5WYB8MkP5hum29IR8f/DAzez31Fg0PQdqZr3qxQWlygBGg+gJ3Aee/JkScRQInrTaRRmWv+M 99XSIzDMfNsg43s2U4DLrw==; Date: Sat, 15 Mar 2025 14:36:29 +0200 Message-Id: <86ikoawjw2.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Markus Triska <triska@HIDDEN> In-Reply-To: <87h63ur0ry.fsf@HIDDEN> (message from Markus Triska on Sat, 15 Mar 2025 12:28:17 +0100) Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN> <86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN> <8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN> <86wmdihy74.fsf@HIDDEN> <87seo5adv9.fsf@HIDDEN> <86a5adi1o4.fsf@HIDDEN> <87seo2qb2w.fsf@HIDDEN> <86cyezomc8.fsf@HIDDEN> <86bju2y2k0.fsf@HIDDEN> <87h63ur0ry.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76186 Cc: 76186 <at> debbugs.gnu.org, stephen.berman@HIDDEN 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: Markus Triska <triska@HIDDEN> > Cc: stephen.berman@HIDDEN, 76186 <at> debbugs.gnu.org > Date: Sat, 15 Mar 2025 12:28:17 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > Ping! Do we still need to discuss this issue? Or can it be closed, > > given my explanations below? > > I can still reproduce the problem on 3 different Emacs installations > (Debian, Ubuntu and OSX), and I would prefer this issue only to be > closed when Emacs handles the example reliably because I consider it > unsaticsfactory that recentering sometimes work, and sometimes not. I thought I explained why this cannot be done as reliably as you expect it to be. > The other remaining question is why you cannot reproduce the issue with > your configuration whereas Steve and I can do so on ours. I don't know.
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 15 Mar 2025 11:28:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 15 07:28:21 2025 Received: from localhost ([127.0.0.1]:39210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ttPgj-0002tH-6Z for submit <at> debbugs.gnu.org; Sat, 15 Mar 2025 07:28:21 -0400 Received: from [78.47.144.35] (port=42590 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <triska@HIDDEN>) id 1ttPgg-0002t7-GA for 76186 <at> debbugs.gnu.org; Sat, 15 Mar 2025 07:28:19 -0400 Received: by metalevel.at (Postfix, from userid 1000) id 4C1939C795; Sat, 15 Mar 2025 12:28:17 +0100 (CET) From: Markus Triska <triska@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN> <86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN> <8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN> <86wmdihy74.fsf@HIDDEN> <87seo5adv9.fsf@HIDDEN> <86a5adi1o4.fsf@HIDDEN> <87seo2qb2w.fsf@HIDDEN> <86cyezomc8.fsf@HIDDEN> <86bju2y2k0.fsf@HIDDEN> Date: Sat, 15 Mar 2025 12:28:17 +0100 Message-ID: <87h63ur0ry.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > Ping! Do we still need to discuss this issue? Or can it be closed, > given my explanations below? I can still reproduce the problem on 3 different Emacs installations (Debian, Ubuntu and OSX), and I would prefer this issue only to be closed when Emacs handles the example reliably because I conside [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in sa-accredit.habeas.com] 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in bl.score.senderscore.com] 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 76186 Cc: 76186 <at> debbugs.gnu.org, stephen.berman@HIDDEN 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.3 (/) Eli Zaretskii <eliz@HIDDEN> writes: > Ping! Do we still need to discuss this issue? Or can it be closed, > given my explanations below? I can still reproduce the problem on 3 different Emacs installations (Debian, Ubuntu and OSX), and I would prefer this issue only to be closed when Emacs handles the example reliably because I consider it unsaticsfactory that recentering sometimes work, and sometimes not. The other remaining question is why you cannot reproduce the issue with your configuration whereas Steve and I can do so on ours. Thank you and all the best, Markus
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 15 Mar 2025 11:08:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 15 07:08:22 2025
Received: from localhost ([127.0.0.1]:39093 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ttPNN-0001GZ-Gx
for submit <at> debbugs.gnu.org; Sat, 15 Mar 2025 07:08:22 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:45908)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1ttPNK-0001Fa-CA
for 76186 <at> debbugs.gnu.org; Sat, 15 Mar 2025 07:08:19 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1ttPNE-0006Z7-Br; Sat, 15 Mar 2025 07:08:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=MlDu4PhGc5Tv2enbie3hTdwMM6VgYp96x9xkXrRYwTs=; b=KEfTE4VC5AYz
84jF9mP1g46dyBMTCZDQ9Lzq6CpG9MrnglT2mjWviYnzcEmPhZWRY54Gh8kY8INO3/93Y+GZFpjqE
LOVq/yIaG8Z1rpnQWaDrEPb47LZ7b07J5U0OP2bNpteAGuVHdlR1BCNA7yYKMbUCz5tN2QvnALVm5
GE3Vwz1O6axv9yM8lHSVtn7PhAdX67m5FKJprOPqHJTI5lFDeGC/c4bFAcS5sEMIRhG9RVh0BIIWo
LVAPBcRsubJzTSrLAsEgM7iZJYtRUtVFCBrErhou7HFsR22KwO6bIIkkFL9S1E4hztY1cYgOdgxcH
OeLkrDLy1V87mhn487gx8A==;
Date: Sat, 15 Mar 2025 13:07:59 +0200
Message-Id: <86bju2y2k0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: stephen.berman@HIDDEN
In-Reply-To: <86cyezomc8.fsf@HIDDEN> (message from Eli Zaretskii on Sun, 02
Mar 2025 10:42:15 +0200)
Subject: Re: bug#76186: 31.0.50;
(recenter 0) sometimes does not recenter as expected
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN>
<86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN>
<8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN>
<86wmdihy74.fsf@HIDDEN> <87seo5adv9.fsf@HIDDEN>
<86a5adi1o4.fsf@HIDDEN> <87seo2qb2w.fsf@HIDDEN> <86cyezomc8.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76186
Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN
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 (---)
Ping! Do we still need to discuss this issue? Or can it be closed,
given my explanations below?
> Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN
> Date: Sun, 02 Mar 2025 10:42:15 +0200
> From: Eli Zaretskii <eliz@HIDDEN>
>
> > From: Stephen Berman <stephen.berman@HIDDEN>
> > Cc: triska@HIDDEN, 76186 <at> debbugs.gnu.org
> > Date: Tue, 25 Feb 2025 16:48:55 +0100
> >
> > >> 20570 else if (CHARPOS (startp) >= BEGV
> > >
> > > This indicates that one of the conditions below
> > >
> > > else if (CHARPOS (startp) >= BEGV
> > > && CHARPOS (startp) <= ZV
> > > && PT >= CHARPOS (startp)
> > > && (CHARPOS (startp) < ZV
> > > /* Avoid starting at end of buffer. */
> > > || CHARPOS (startp) == BEGV
> > > || !window_outdated (w)))
> > >
> > > yields false, but which one?
> >
> > (gdb) p CHARPOS (startp) >= BEGV
> > $24 = 1
> > (gdb) p CHARPOS (startp) <= ZV
> > $25 = 1
> > (gdb) p PT >= CHARPOS (startp)
> > $26 = 1
> > (gdb) p CHARPOS (startp) < ZV
> > $27 = 0
> > (gdb) p CHARPOS (startp) == BEGV
> > $28 = 0
> > (gdb) p !window_outdated (w)
> > $29 = 0
>
> So window_outdated returned non-zero. That function is just
>
> bool
> window_outdated (struct window *w)
> {
> struct buffer *b = XBUFFER (w->contents);
> return (w->last_modified < BUF_MODIFF (b)
> || w->last_overlay_modified < BUF_OVERLAY_MODIFF (b));
> }
>
> which means the window's last_modified flag was not updated by the
> previous redisplay cycle for some reason. That probably happens
> because some code called mark_window_display_accurate with last
> argument 'false', or maybe because that function was not called at the
> end of the previous (1st) redisplay cycle in this scenario (recall
> that redisplay_window is called twice in this scenario, and it's the
> second call that recenters). If you can find out which call was that,
> maybe it will tell us something useful, but in general, if the
> window's display is outdated, the display engine will indeed recenter,
> because that means the information in window-start is unreliable. So
> I'm guessing that something in the convoluted reproduction recipe
> causes Emacs to decide that the window was not fully redrawn, or that
> something happened after the 1st redisplay which made the window
> outdated, and that is why it centers point in the window.
>
> > Does the trace answer your questions? If so, can you connect the dots
> > for me, because I still don't see why the recentering happens.
>
> Recentering of point in the window is the default strategy of
> redisplaying a window when all else failed or was found inapplicable.
> That's what happens here, for some subtle reason whose cause is in the
> recipe. AFAIU, point is still at EOB when this happens, so the only
> problem is the expectation that window-start will always be at EOB
> after the call (recenter 0), which evidently is not 100% reliable.
>
> Thanks.
>
>
>
>
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 2 Mar 2025 08:42:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 02 03:42:30 2025
Received: from localhost ([127.0.0.1]:52824 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1toeu5-0001lt-G4
for submit <at> debbugs.gnu.org; Sun, 02 Mar 2025 03:42:29 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:52386)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1toeu2-0001lB-2d
for 76186 <at> debbugs.gnu.org; Sun, 02 Mar 2025 03:42:27 -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 1toetw-0007rg-5S; Sun, 02 Mar 2025 03:42:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=SalGVa6xDgZzBfpkbSd/NiMVWbiCWp3EBP2v9RCage4=; b=Re4dn8DSq18P
7QfGEFyfPlEISmf+mmBXkkgCB8lGhhBxWr7j2UGjQlkZaad9cq0QCSzQoPSA0u7BZgpoKWqBrX60j
fpwPjruiFS2Rt9hCq1BXv3A1byf3AwIkwtIQAjA+R3fQforti5yEOcIZGgvz13AnEkWw8N27B5j4n
YS3/3o/1KaqsWjdFfz15aGOP19gzuqD3BsgfUnxZCTnmkndy+kETrvbS+XzyDNZ64WytxPQA6F+Fp
d9CNrQt5xbDxvoaaQQCJhB2ZSYmPSRIKjVSdFgwYM7QMUUcdLO0hCUs8oeYAZ7sJoQWw4SwAmrDKx
bkK6R23sN1AKADt+tBPUCg==;
Date: Sun, 02 Mar 2025 10:42:15 +0200
Message-Id: <86cyezomc8.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stephen Berman <stephen.berman@HIDDEN>
In-Reply-To: <87seo2qb2w.fsf@HIDDEN> (message from Stephen Berman on Tue, 25
Feb 2025 16:48:55 +0100)
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
expected
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN>
<86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN>
<8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN>
<86wmdihy74.fsf@HIDDEN> <87seo5adv9.fsf@HIDDEN>
<86a5adi1o4.fsf@HIDDEN> <87seo2qb2w.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76186
Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN
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: Stephen Berman <stephen.berman@HIDDEN>
> Cc: triska@HIDDEN, 76186 <at> debbugs.gnu.org
> Date: Tue, 25 Feb 2025 16:48:55 +0100
>
> >> 20570 else if (CHARPOS (startp) >= BEGV
> >
> > This indicates that one of the conditions below
> >
> > else if (CHARPOS (startp) >= BEGV
> > && CHARPOS (startp) <= ZV
> > && PT >= CHARPOS (startp)
> > && (CHARPOS (startp) < ZV
> > /* Avoid starting at end of buffer. */
> > || CHARPOS (startp) == BEGV
> > || !window_outdated (w)))
> >
> > yields false, but which one?
>
> (gdb) p CHARPOS (startp) >= BEGV
> $24 = 1
> (gdb) p CHARPOS (startp) <= ZV
> $25 = 1
> (gdb) p PT >= CHARPOS (startp)
> $26 = 1
> (gdb) p CHARPOS (startp) < ZV
> $27 = 0
> (gdb) p CHARPOS (startp) == BEGV
> $28 = 0
> (gdb) p !window_outdated (w)
> $29 = 0
So window_outdated returned non-zero. That function is just
bool
window_outdated (struct window *w)
{
struct buffer *b = XBUFFER (w->contents);
return (w->last_modified < BUF_MODIFF (b)
|| w->last_overlay_modified < BUF_OVERLAY_MODIFF (b));
}
which means the window's last_modified flag was not updated by the
previous redisplay cycle for some reason. That probably happens
because some code called mark_window_display_accurate with last
argument 'false', or maybe because that function was not called at the
end of the previous (1st) redisplay cycle in this scenario (recall
that redisplay_window is called twice in this scenario, and it's the
second call that recenters). If you can find out which call was that,
maybe it will tell us something useful, but in general, if the
window's display is outdated, the display engine will indeed recenter,
because that means the information in window-start is unreliable. So
I'm guessing that something in the convoluted reproduction recipe
causes Emacs to decide that the window was not fully redrawn, or that
something happened after the 1st redisplay which made the window
outdated, and that is why it centers point in the window.
> Does the trace answer your questions? If so, can you connect the dots
> for me, because I still don't see why the recentering happens.
Recentering of point in the window is the default strategy of
redisplaying a window when all else failed or was found inapplicable.
That's what happens here, for some subtle reason whose cause is in the
recipe. AFAIU, point is still at EOB when this happens, so the only
problem is the expectation that window-start will always be at EOB
after the call (recenter 0), which evidently is not 100% reliable.
Thanks.
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 25 Feb 2025 15:49:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 25 10:49:14 2025
Received: from localhost ([127.0.0.1]:48040 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tmxBK-0006Qm-0J
for submit <at> debbugs.gnu.org; Tue, 25 Feb 2025 10:49:14 -0500
Received: from mout.gmx.net ([212.227.17.20]:40035)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <stephen.berman@HIDDEN>)
id 1tmxBE-0006QS-Jq
for 76186 <at> debbugs.gnu.org; Tue, 25 Feb 2025 10:49:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net;
s=s31663417; t=1740498537; x=1741103337; i=stephen.berman@HIDDEN;
bh=WNJMYbmCgA1bvOnABslDHeQqN6cxIGQYIO+LsSuJhGM=;
h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date:
Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc:
content-transfer-encoding:content-type:date:from:message-id:
mime-version:reply-to:subject:to;
b=i0V7zVeRqrGzD4Bl50UUczKscGVE59OWLlx6zJNfDqbHgJi5oA2pMXZJsxr9Hylx
o4ks8TpBeB7CdS4rBknTwiqzn+xIJ5/Ee7u/0Szd57wijObm6Igekw0Bt9m9GeaWT
lr+z0NoRVtaKGu1vU+uT3CLIeldJU+9vi4QlovnpqM2QjFJNz89y13U9WnuWrNJTi
AhVLGLed+MqEF6XViGaXGEnyG5QeqqFo1M1K3cP39A/eL51hK7MfCb6I0PzpWYtz7
fZtH2gQMPOvzhgE7rV3T/0ynLQipK2Cf8xlHWYLOICcWM4QbMMucB9LVm7/WNJL9D
5QK/SMQB0lOk3Sfwqw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfssd ([88.130.50.54]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1Ma24y-1tqA9N0RbI-00Ivy2; Tue, 25
Feb 2025 16:48:57 +0100
From: Stephen Berman <stephen.berman@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
expected
In-Reply-To: <86a5adi1o4.fsf@HIDDEN>
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN>
<86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN>
<8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN>
<86wmdihy74.fsf@HIDDEN> <87seo5adv9.fsf@HIDDEN>
<86a5adi1o4.fsf@HIDDEN>
Date: Tue, 25 Feb 2025 16:48:55 +0100
Message-ID: <87seo2qb2w.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:abDa13TZ94RtawQphN9YqLBH7tJ2TbMgnKQtz4Liz3ndEORS8Nt
ehbVfwso5ncZNHXdV1wd3eclIgO4G2K57/AAu+8prUcaofvZW6uLzFSuPaYN46XgPi5DbSa
I/VCMYKnB298vJXYek9n1WIQmy6DIv8kZL+lRUCDT33IYJFH/5uPkRXEDinnLV480+PG4we
7KIHIfKSlb6CB+uK36mgg==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:3nIkjWLoyS0=;gKzmsY/eTta94cj5J0IA5idp1Qx
AdjgmiSCb4GRCVVwqSITkRjMQc81sSbf+3WlRRBvczT8Na9BFM33uV5Tth96MwFlR5RLaVvAC
ylqEcqxSb5FN60pCPZDZ9DXSUiT+U8usnhysnuoVkbuOyOxu4LFhxlue+UAfAidbxVGD0PEXP
tJm+WdSwZXUL+H4RC3xuWV/ONabGuxTiujp0pMDUqGXK84r/exZ53VAg5xb9T/CCHPYhSSORs
VSbIDCV1/4gnrqVxxgacAsYM9hWQxEW3HtCqlQpmKL+GjfTdrazgJNQarpt/9Ki1ErL001Lo+
OWA002eJYmX66rPKLVQWf3inE62h5+rSdpd7ul9sRl1odez3BWgRPqoK55ZlD2LEUe55c2R3L
O4NRjIayB08+lxmj1whiEqsQN61yo6FiLLsrIoROXo/g8z29B5+4gp9uboeKkjzEFfGMpDFsN
wcHSlFm78hsy5hSU2x5iQG96y/6DN5MgVEstpk08cPMJxq3gkdx+x6UgWanrEadXvrAnsGWXH
Y/S+9G6UL0VdNJLriAiGcUb7a7iOiyjztjZtAFOkoEkRLVem6Ocq1/BWBEuP0itBBnZHu7jtf
zkw6MBlQIQ4B2yY3fryab/d4mwzrenleoDg0piRcwUucSJY9SwRNPr1FQ0Zw2QAJYYZTLTUWH
WEUpS2SZxqA0lBL48lWyRhQTV41URxw/DlC3+nPtBIXkNnqTJFl4MfGpsciyHi2e3rbEMykPo
ouIICvDeJ0iNYKkGS/EEElEilMXM2fezZ0C3rA+kOrRCW0A+2bc+ylB/zlwbUNm8ypgbp1VA4
S9AFDLB5YUK2W5COSlBedq3aAoTWvBaHGffz+Y/qZ0GJvuDiW98zieatpYUajXU5HCoUYQ3tE
X0GpFezKsAEn8y5v5tBZYHe81LZAhp/R85KZbiwR2yz0OLgtznNy+qk1jE0N06P5GzWkX0ubS
Z+mIUs3CvQbvJHbhoXvIGWwjdNG4NGt9z/srS9Vg8MDFE2uav7awnSDjCUgO9vPn7if61Z4r+
G4efcdEvjCeERjRdJQe4TPSbqw8X0bq2FzweCqHwBWAhEmZ/Y35gmFvjyMCFD+oVhs+YVHw8K
sLXUhl0ZD6+WVtuRwIqws0qAHD/QJnMLmJ38bb+5Yxf8PrUkSgd4QPGEuvZbWP0zbCD8DsMCJ
qo7lFpfGzxvd9X29eWTXXEGdScB37IVV+AM9QI9HOqJAJvFgqQ4yfISIocN8nCaZFxp5Iv217
I8Ad3aTDdgzWH5mCGJLH/8Qa2tbK3JqDgfU4GjxNQ/BgrhpIVA6SAG3TcxxTDx8vX1ZuycEsz
GVytQr2VDjhjphG3Qg3pE7q9pSmc6Jv7m471UNCnDzG98ys6PH7i6bN6nR68a64epLUymE6Qe
6qF/TG78C4imj9Dbmr9ycPNlB+JCGF/CuyCIIXORczXF4voZPWs05UjSEX7a0MRc9xwgoIDHV
bWWXg+A==
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 76186
Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN
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 (-)
On Sun, 23 Feb 2025 09:02:35 +0200 Eli Zaretskii <eliz@HIDDEN> wrote:
>> From: Stephen Berman <stephen.berman@HIDDEN>
>> Cc: triska@HIDDEN, 76186 <at> debbugs.gnu.org
>> Date: Sat, 22 Feb 2025 22:06:18 +0100
>>
>> As you can see, after hitting the window.c breakpoint and stepping over
>> set_marker_both, window-start is at 793, i.e. point-max, which is the
>> expected position after invoking `(recenter 0)'. After continuing and
>> hitting the xdisp.c breakpoint, I stepped through the code and saw
>> w->force_start get set to true, then stepped further until
>> redisplay_window_0, then continued and hit the breakpoint again, and no=
w
>> w->force_start was false. Then I stepped further until
>> SET_TEXT_POS_FROM_MARKER (startp, w->start), after which window-start
>> was now at 671, the value displayed in the message after one iteration,
>> indicating the unexpected recentering. I cannot tell what caused
>> window-start to change from 793 to 671.
>
> Thanks.
>
> There are too many unknowns here that need to become knowns.
>
> First, before the first call to redisplay_window returns, it does
> this:
>
> /* Restore current_buffer and value of point in it. The window
> update may have changed the buffer, so first make sure `opoint'
> is still valid (Bug#6177). */
> if (CHARPOS (opoint) < BEGV)
> TEMP_SET_PT_BOTH (BEGV, BEGV_BYTE);
> else if (CHARPOS (opoint) > ZV)
> TEMP_SET_PT_BOTH (Z, Z_BYTE);
> else if (ochars_modiff =3D=3D CHARS_MODIFF)
> TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
> else
> {
> /* If the buffer was modified while we were redisplaying it, we
> cannot trust the correspondence between character and byte
> positions. This can happen, for example, if we are
> redisplaying *Messages* and some Lisp, perhaps invoked by
> display_mode_lines, signals an error which caused something
> added/deleted to/from the buffer text. */
> TEMP_SET_PT_BOTH (CHARPOS (opoint), CHAR_TO_BYTE (CHARPOS (opoint)=
));
> }
> set_buffer_internal_1 (old);
> /* Avoid an abort in TEMP_SET_PT_BOTH if the buffer has become
> shorter. This can be caused by log truncation in *Messages*. */
> if (CHARPOS (lpoint) <=3D ZV)
> {
> if (lchars_modiff =3D=3D CHARS_MODIFF)
> TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));
> else
> TEMP_SET_PT_BOTH (CHARPOS (lpoint), CHAR_TO_BYTE (CHARPOS (lpoint)));
> }
>
> Your trace indicates that TEMP_SET_PT_BOTH was called twice when
> executing this fragment, but you haven't shown the values of point
> after each one of them. It is crucial to understand where point was
> after the first call to redisplay_window, because any subsequent
> scrolling of the window depends on whether point is fully visible in
> the viewport. So please show the value of point as set by these two
> calls to TEMP_SET_PT_BOTH.
Thread 1 "emacs" hit Breakpoint 3, redisplay_window (window=3DXIL(0x555555=
c826c5),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:21195
21195 if (CHARPOS (opoint) < BEGV)
(gdb) p w->start
$1 =3D XIL(0x555555d2782d)
(gdb) pr $1
#<marker at 793 in smple>
(gdb) p PT
$2 =3D 793
(gdb) p ZV
$3 =3D 793
(gdb) n
[Thread 0x7fffde16e6c0 (LWP 28706) exited]
21197 else if (CHARPOS (opoint) > ZV)
(gdb)
21199 else if (ochars_modiff =3D=3D CHARS_MODIFF)
(gdb)
21200 TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
(gdb)
21211 set_buffer_internal_1 (old);
(gdb) p PT
$4 =3D 793
(gdb) n
21214 if (CHARPOS (lpoint) <=3D ZV)
(gdb)
21216 if (lchars_modiff =3D=3D CHARS_MODIFF)
(gdb)
21217 TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));
(gdb)
21222 unbind_to (count, Qnil);
(gdb) p PT
$5 =3D 793
> Next, at the very beginning of redisplay_window we have this:
>
> if (!just_this_one_p && needs_no_redisplay (w))
> return;
>
> Thus, the second call to redisplay_window was supposed to return
> immediately if these conditions were true. Since it didn't, and
> just_this_one_p is false, we can conclude that needs_no_redisplay
> returned false, but which condition inside it caused that?
(gdb) break xdisp.c:20081
Breakpoint 4 at 0x5555555f8ae8: file /home/steve/src/emacs/emacs-master/sr=
c/xdisp.c, line 20081.
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=3DXIL(0x555555=
c828e5),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:20081
20081 if (!just_this_one_p && needs_no_redisplay (w))
(gdb) p !just_this_one_p
$6 =3D 1
(gdb) p needs_no_redisplay (w)
$7 =3D false
(gdb) p REDISPLAY_SOME_P ()
$8 =3D 0
(gdb) p !w->redisplay
$9 =3D 0
(gdb) p !w->update_mode_line
$10 =3D 0
(gdb) p !f->face_change
$11 =3D 1
(gdb) p !f->redisplay
$12 =3D 0
(gdb) p !buffer->text->redisplay
$13 =3D 0
(gdb) p window_point (w) =3D=3D w->last_point
$14 =3D 0
> Next, this:
>
>> 20520 if (current_matrix_up_to_date_p
>> (gdb)
>> 20540 else if (w->start_at_line_beg
>
> indicates that current_matrix_up_to_date_p is false, but why is that?
> It is set around line 20160:
>
> current_matrix_up_to_date_p
> =3D (w->window_end_valid
> && !current_buffer->clip_changed
> && !current_buffer->prevent_redisplay_optimizations_p
> && !window_outdated (w)
> && !composition_break_at_point
> && !hscrolling_current_line_p (w));
>
> Which one of these causes current_matrix_up_to_date_p to become false?
> Or maybe it starts at true, but becomes false below:
>
> /* When windows_or_buffers_changed is non-zero, we can't rely
> on the window end being valid, so set it to zero there. */
> if (windows_or_buffers_changed)
> {
> /* If window starts on a continuation line, maybe adjust the
> window start in case the window's width changed. */
> if (XMARKER (w->start)->buffer =3D=3D current_buffer)
> compute_window_start_on_continuation_line (w);
>
> w->window_end_valid =3D false;
> /* If so, we also can't rely on current matrix
> and should not fool try_cursor_movement below. */
> current_matrix_up_to_date_p =3D false;
> }
(gdb) break xdisp.c:20520
Breakpoint 5 at 0x5555555f92ea: file /home/steve/src/emacs/emacs-master/sr=
c/xdisp.c, line 20520.
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 3, redisplay_window (window=3DXIL(0x555555=
c828e5),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:21195
21195 if (CHARPOS (opoint) < BEGV)
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=3DXIL(0x555555=
c826c5),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:20081
20081 if (!just_this_one_p && needs_no_redisplay (w))
(gdb)
Continuing.
Thread 1 "emacs" hit Breakpoint 5, redisplay_window (window=3DXIL(0x555555=
c826c5),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:20520
20520 if (current_matrix_up_to_date_p
(gdb) p current_matrix_up_to_date_p
$15 =3D <optimized out>
(gdb) p w->window_end_valid
$16 =3D false
(gdb) p !current_buffer->clip_changed
$17 =3D 1
(gdb) p !current_buffer->prevent_redisplay_optimizations_p
$18 =3D 0
(gdb) p !window_outdated (w)
$19 =3D 0
(gdb) p !composition_break_at_point
$20 =3D 1
(gdb) p !hscrolling_current_line_p (w)
$21 =3D 1
(gdb) n
20540 else if (w->start_at_line_beg
(gdb) p current_matrix_up_to_date_p
$22 =3D <optimized out>
> Next,
>
>> (gdb)
>> 20556 else if ((tem =3D try_window_id (w)) !=3D 0)
>> (gdb)
>
> indicates that try_window_id returned zero. I'd be interested to know
> why.
(gdb) n
20556 else if ((tem =3D try_window_id (w)) !=3D 0)
(gdb) p try_window_id (w)
$23 =3D 0
(gdb) break xdisp.c:22148
Breakpoint 6 at 0x5555555f709a: file /home/steve/src/emacs/emacs-master/sr=
c/xdisp.c, line 22149.
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 6, try_window_id (w=3Dw@entry=3D0x555555c8=
26c0)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:22149
22149 {
(gdb) n
22150 struct frame *f =3D XFRAME (w->frame);
(gdb)
22155 if (is_tty_root_frame_with_visible_child (f))
(gdb)
22158 struct glyph_matrix *current_matrix =3D w->current_matrix;
(gdb)
22159 struct glyph_matrix *desired_matrix =3D w->desired_matrix;
(gdb)
22166 ptrdiff_t delta =3D 0, delta_bytes =3D 0, stop_pos;
(gdb)
22191 SET_TEXT_POS_FROM_MARKER (start, w->start);
(gdb)
22195 if (MINI_WINDOW_P (w))
(gdb) 22199 if (windows_or_buffers_changed || f->cursor_type_changed)
(gdb)
redisplay_window (window=3DXIL(0x555555c826c5),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:20570
20570 else if (CHARPOS (startp) >=3D BEGV
>> 20570 else if (CHARPOS (startp) >=3D BEGV
>
> This indicates that one of the conditions below
>
> else if (CHARPOS (startp) >=3D BEGV
> && CHARPOS (startp) <=3D ZV
> && PT >=3D CHARPOS (startp)
> && (CHARPOS (startp) < ZV
> /* Avoid starting at end of buffer. */
> || CHARPOS (startp) =3D=3D BEGV
> || !window_outdated (w)))
>
> yields false, but which one?
(gdb) p CHARPOS (startp) >=3D BEGV
$24 =3D 1
(gdb) p CHARPOS (startp) <=3D ZV
$25 =3D 1
(gdb) p PT >=3D CHARPOS (startp)
$26 =3D 1
(gdb) p CHARPOS (startp) < ZV
$27 =3D 0
(gdb) p CHARPOS (startp) =3D=3D BEGV
$28 =3D 0
(gdb) p !window_outdated (w)
$29 =3D 0
>> 20684 if ((0 < scroll_conservatively
>> (gdb)
>> 20732 init_iterator (&it, w, PT, PT_BYTE, NULL, DEFAULT_FACE_ID);
>> (gdb)
>> 20733 it.current_y =3D it.last_visible_y;
>> (gdb)
>> 20734 if (centering_position < 0)
>
> Here we arrive at a place where redisplay_window decided it must
> redraw the window by recentering point in the viewport, and that's
> what happens afterwards. So the above questions should explain why
> this happens, instead of the expected result: redisplay_window
> deciding that the window's display is already up-to-day and needs no
> display changes.
Does the trace answer your questions? If so, can you connect the dots
for me, because I still don't see why the recentering happens. If not,
can you tell what's still missing?
Steve Berman
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 23 Feb 2025 07:02:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 23 02:02:52 2025
Received: from localhost ([127.0.0.1]:59098 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tm60p-0006oD-Tk
for submit <at> debbugs.gnu.org; Sun, 23 Feb 2025 02:02:52 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:40814)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tm60l-0006ns-8S
for 76186 <at> debbugs.gnu.org; Sun, 23 Feb 2025 02:02:48 -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 1tm60f-0002u6-0K; Sun, 23 Feb 2025 02:02:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=PmeqFKvz4xe6Ue54HmT+Gj+mHa9Ih6ZY3ppdo5JF46s=; b=HkXtYcwjxh2t
nwuGiibhahoX3DFjnHHv4fvdgA9lyNp7b/qGowsitN+Aq5K8bIGU43d5UqHNH49Hn5Zt+H2XCYHj0
wtYvTtKmeY2DolrQhYvlJhpaUsJZeXWYKQNTo6Ww8DQW6Y+zJyl5dD06gbCH40YytW1d0DqfUn4Jl
Ukk+3TICc1m1eWiLGrMf1WM0TT0pzTw59IDVHSUGrid0/McCBl8DOU+IBTZ/GLpVkgvIM9zNq1auo
ev8E5YOxcX2laSnZVjeuO0opbBQTh8Fd5uyC5VYAfKCaX/GDw2AXIcfx6Rt7p1RerAipR9vU7A4Tm
Gq3ZP98RxnqIPvlMDJMPpQ==;
Date: Sun, 23 Feb 2025 09:02:35 +0200
Message-Id: <86a5adi1o4.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stephen Berman <stephen.berman@HIDDEN>
In-Reply-To: <87seo5adv9.fsf@HIDDEN> (message from Stephen Berman on Sat, 22
Feb 2025 22:06:18 +0100)
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
expected
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN>
<86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN>
<8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN>
<86wmdihy74.fsf@HIDDEN> <87seo5adv9.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76186
Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN
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: Stephen Berman <stephen.berman@HIDDEN>
> Cc: triska@HIDDEN, 76186 <at> debbugs.gnu.org
> Date: Sat, 22 Feb 2025 22:06:18 +0100
>
> As you can see, after hitting the window.c breakpoint and stepping over
> set_marker_both, window-start is at 793, i.e. point-max, which is the
> expected position after invoking `(recenter 0)'. After continuing and
> hitting the xdisp.c breakpoint, I stepped through the code and saw
> w->force_start get set to true, then stepped further until
> redisplay_window_0, then continued and hit the breakpoint again, and now
> w->force_start was false. Then I stepped further until
> SET_TEXT_POS_FROM_MARKER (startp, w->start), after which window-start
> was now at 671, the value displayed in the message after one iteration,
> indicating the unexpected recentering. I cannot tell what caused
> window-start to change from 793 to 671.
Thanks.
There are too many unknowns here that need to become knowns.
First, before the first call to redisplay_window returns, it does
this:
/* Restore current_buffer and value of point in it. The window
update may have changed the buffer, so first make sure `opoint'
is still valid (Bug#6177). */
if (CHARPOS (opoint) < BEGV)
TEMP_SET_PT_BOTH (BEGV, BEGV_BYTE);
else if (CHARPOS (opoint) > ZV)
TEMP_SET_PT_BOTH (Z, Z_BYTE);
else if (ochars_modiff == CHARS_MODIFF)
TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
else
{
/* If the buffer was modified while we were redisplaying it, we
cannot trust the correspondence between character and byte
positions. This can happen, for example, if we are
redisplaying *Messages* and some Lisp, perhaps invoked by
display_mode_lines, signals an error which caused something
added/deleted to/from the buffer text. */
TEMP_SET_PT_BOTH (CHARPOS (opoint), CHAR_TO_BYTE (CHARPOS (opoint)));
}
set_buffer_internal_1 (old);
/* Avoid an abort in TEMP_SET_PT_BOTH if the buffer has become
shorter. This can be caused by log truncation in *Messages*. */
if (CHARPOS (lpoint) <= ZV)
{
if (lchars_modiff == CHARS_MODIFF)
TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));
else
TEMP_SET_PT_BOTH (CHARPOS (lpoint), CHAR_TO_BYTE (CHARPOS (lpoint)));
}
Your trace indicates that TEMP_SET_PT_BOTH was called twice when
executing this fragment, but you haven't shown the values of point
after each one of them. It is crucial to understand where point was
after the first call to redisplay_window, because any subsequent
scrolling of the window depends on whether point is fully visible in
the viewport. So please show the value of point as set by these two
calls to TEMP_SET_PT_BOTH.
Next, at the very beginning of redisplay_window we have this:
if (!just_this_one_p && needs_no_redisplay (w))
return;
Thus, the second call to redisplay_window was supposed to return
immediately if these conditions were true. Since it didn't, and
just_this_one_p is false, we can conclude that needs_no_redisplay
returned false, but which condition inside it caused that?
Next, this:
> 20520 if (current_matrix_up_to_date_p
> (gdb)
> 20540 else if (w->start_at_line_beg
indicates that current_matrix_up_to_date_p is false, but why is that?
It is set around line 20160:
current_matrix_up_to_date_p
= (w->window_end_valid
&& !current_buffer->clip_changed
&& !current_buffer->prevent_redisplay_optimizations_p
&& !window_outdated (w)
&& !composition_break_at_point
&& !hscrolling_current_line_p (w));
Which one of these causes current_matrix_up_to_date_p to become false?
Or maybe it starts at true, but becomes false below:
/* When windows_or_buffers_changed is non-zero, we can't rely
on the window end being valid, so set it to zero there. */
if (windows_or_buffers_changed)
{
/* If window starts on a continuation line, maybe adjust the
window start in case the window's width changed. */
if (XMARKER (w->start)->buffer == current_buffer)
compute_window_start_on_continuation_line (w);
w->window_end_valid = false;
/* If so, we also can't rely on current matrix
and should not fool try_cursor_movement below. */
current_matrix_up_to_date_p = false;
}
Next,
> (gdb)
> 20556 else if ((tem = try_window_id (w)) != 0)
> (gdb)
indicates that try_window_id returned zero. I'd be interested to know
why.
> 20570 else if (CHARPOS (startp) >= BEGV
This indicates that one of the conditions below
else if (CHARPOS (startp) >= BEGV
&& CHARPOS (startp) <= ZV
&& PT >= CHARPOS (startp)
&& (CHARPOS (startp) < ZV
/* Avoid starting at end of buffer. */
|| CHARPOS (startp) == BEGV
|| !window_outdated (w)))
yields false, but which one?
> 20684 if ((0 < scroll_conservatively
> (gdb)
> 20732 init_iterator (&it, w, PT, PT_BYTE, NULL, DEFAULT_FACE_ID);
> (gdb)
> 20733 it.current_y = it.last_visible_y;
> (gdb)
> 20734 if (centering_position < 0)
Here we arrive at a place where redisplay_window decided it must
redraw the window by recentering point in the viewport, and that's
what happens afterwards. So the above questions should explain why
this happens, instead of the expected result: redisplay_window
deciding that the window's display is already up-to-day and needs no
display changes.
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 22 Feb 2025 21:06:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 22 16:06:33 2025
Received: from localhost ([127.0.0.1]:57406 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tlwhk-0007ri-0V
for submit <at> debbugs.gnu.org; Sat, 22 Feb 2025 16:06:32 -0500
Received: from mout.gmx.net ([212.227.15.15]:54545)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <stephen.berman@HIDDEN>)
id 1tlwhf-0007rP-9Q
for 76186 <at> debbugs.gnu.org; Sat, 22 Feb 2025 16:06:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net;
s=s31663417; t=1740258380; x=1740863180; i=stephen.berman@HIDDEN;
bh=3nSudNlqM78Oq/SuYKpWixXu2MTU+iW3RBnttNIReUA=;
h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date:
Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc:
content-transfer-encoding:content-type:date:from:message-id:
mime-version:reply-to:subject:to;
b=deShXdoKSKPi+jpd2B+1m/0gHGfBEpzUQGp6T/TO/zaXf8y9NvNvOwtg2E2VhznA
bsqppIZ24vZbcix91K2HC2PdnX2l6VfJ6h6rAHKAHnzj27K9mBG/EgcsxeKuBF3hx
Yp6HLcVYelJtgNiWaZorgltFNanqu1POFzkHfmjcFFKJIIwocYLSMe0Hw0JRHXCCo
GK2yWHNZmUdOnaG1x2ZMjbwuRYPeS2llvd0TIFR12v1xamGeqlaQlRiWri2HapfZE
U3C6x/08zie6wY3dLJdU1fmU7qhsDbaxYZa0v2/yxfJ82vtzfTk/fQ/UufI2KcCaW
8qgzjPbgiwXorOnuHw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfssd ([88.130.50.215]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1MeCtZ-1tDi4x1KcB-00eOGb; Sat, 22
Feb 2025 22:06:20 +0100
From: Stephen Berman <stephen.berman@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
expected
In-Reply-To: <86wmdihy74.fsf@HIDDEN>
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN>
<86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN>
<8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN>
<86wmdihy74.fsf@HIDDEN>
Date: Sat, 22 Feb 2025 22:06:18 +0100
Message-ID: <87seo5adv9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:6xTCpEMOtvrLJazm8zgYQOJdhfzZnC2mbcnRyww2wB5gSiih4hy
VjsCpnvj2aniAdi/ZCr8TmRAJnomNw/UKmyAu31oKLJIce9bME2K1V5zK4uWjk6o8T3O5Fg
o6Mh3ZezV2k1jGFwEkN4QMbadMSJZYWZ7n4VHNV98gH1O9OOC7JUCrMK1wfTnfK2+GiWbul
bdrkXzbkuB3pgSfQCwrAA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:UVe6/rpRcK4=;uKShJ9PncdfcBOYgEZ8wKHc7Bxi
jReCHazfNqAftVFxXGuk0QVnEeOu96adi9lI1Dxo56bzjz+wuYHNkbHkUROK/zKGjR5t2zN0P
4F1cSyOj3qe7suyaMrFK3406cJidcHrY2JXxkMTHXa1kGaXHJAUGE9/rQEC2MfgYQKu8ifLBc
xJh52rXppa0eOWxN2hWnVEPcMAePwnPnr0V9Cr0pLIukWhtl+H395ukTGIkN7ueJHHTFyDiOB
S0x8erRiSyoQmjEaxE2fMnJjSWag2zHIxCc3owbOK600nzT8je2oKgcsAbfDHGzhbG0CKfdUO
IPu8OCjaM5PoWHbs6ULgs9aZWwaFJ4EOF4ri3zGIv+A7d7s1FPxef/goGfV6cL0xvHgosSWHr
77JE/AUSdw/qpghjCXPbPshcEx/7kO9ZsHPprKexLnJ1bQnLqII1AWZypNEG6u087CEL2qH+s
aAunj2EYDlBJQBCRgpTlUTjl+8QN6yEqG6KEaMAr/ENPyLmfIuv1PpNRLU5yZtS/ZMApE0F1T
Df71GTKZ8FC++j0NgqJvpadud7Iv8htMt3V6ywo0ALI1mGQVUdmkJ7sn4fBpWOaCBH4IKCHNd
3RlircGmlVIZ7jTucCwWl/8IWRrUm1R9oRC4H0nphbBFaKrxbofcGQqfkJSYPBEo3jtHVcu8x
Mg0bDjuTWSqHDuLpkZ+bcSOSJ2K4+UKcWbl8fiJehQkp2S3vox5H7kH1Hj/t6zFz0YPeHLQ7s
mJ4PtQzHOziHOjOaBxvXkcjGLDLVs1xLXN55sD9ArhsFcZ1jcy95Ie7KxRnYF7ZeiH2RsYgP1
bnhK2oI71lFhVl7zvXzPPsuz97XACfsKA32gFj/E/bVz0YTw7iBXDWsvb8gV0XhvuJzYolTcr
rJBm3C1kl0ijpoMlACWyTdJAH0pG8EzhkAaP40OdLmGe0wzv8U+cLHNW7h1QGDHLQeNfUHphV
s6K92o6g89chvaC72isfRs5glSb1MEPJvWoQaiOMtaLqoisMdVjrlIRifp3GR0JDfavfU4IbA
/l29dm8GEdliNCowfImn5Jx/+aoylN41GwKshCFY+egIsMAIy1MR8LhNYPJl0R9oV23hDVe9y
1UTAow+eRy4l4QuQEfMaSgO4EilkRhW7kSwXvL2V0zt1f5T6XkCeHdE4a44hrdFIGghr/BmmZ
U7e4wW6A6qT0cE87AjO1HxUDMm+0DD1GPX+/x7Z8AJ3LzwQ/gFVGYRNxjKhdRed6k4mL3+IUP
mGCgmpxh/FeFTXEQU4Isn5nOiaolfuODBBqp45rCS4qnVgRt3ScdYINLBFTBIzYIATuIh2GDQ
/yONCD8nFp2xSB0GUgi9LQizohWfpuPqOB9Cc/zfGfkGEcXjtCxom5HIJ45/gAVEASLk+/3PL
86Qd2UxHue+jQxVRznyFqSgDk08KVJ8gOnEonMRg8TcTMNwLq+OdrQ59ib9ODTk0burN3OvvA
bCGO8bQ==
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 76186
Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN
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 (-)
On Sat, 22 Feb 2025 16:05:19 +0200 Eli Zaretskii <eliz@HIDDEN> wrote:
>> From: Stephen Berman <stephen.berman@HIDDEN>
>> Cc: triska@HIDDEN, 76186 <at> debbugs.gnu.org
>> Date: Sat, 22 Feb 2025 14:46:34 +0100
>>
>> On Sat, 22 Feb 2025 15:32:28 +0200 Eli Zaretskii <eliz@HIDDEN> wrote:
[...]
>> > Some parts of what you describe seem to indicate that the problem is
>> > not with 'recenter' itself, but with the following redisplay cycle,
>> > which, for some reason, considers the window-start position
>> > inappropriate and recenters point on display. But I have no idea why=
,
>> > and it is impossible to debug this when the problem happens as part o=
f
>> > 500 iterations.
>>
>> I agree, and the apparent ineffectiveness of Edebug in this case is als=
o
>> frustrating. I could try using gdb with the test configuration where I
>> consistly get the "unexpected recentering" after one iteration; can you
>> suggest where to set the break point and any other input that may be
>> helpful?
>
> 'recenter' takes effect in two parts: first Emacs determines where to
> put window-start, and then redisplay redraws the window according to
> that.
>
> The first part is in window.c, in Frecenter, where we have this:
>
> /* Set the new window start. */
> set_marker_both (w->start, w->contents, charpos, bytepos);
>
> So first we should determine whether this code determines the
> window-start point as expected. If not, the reason is inside the
> implementation of 'recenter'.
>
> The second part is in xdisp.c:redisplay_window, where it attempts to
> obey the optional_new_start flag of the window. It starts here:
>
> /* If someone specified a new starting point but did not insist,
> check whether it can be used. */
> if ((w->optional_new_start || window_frozen_p (w))
> && CHARPOS (startp) >=3D BEGV
> && CHARPOS (startp) <=3D ZV)
> {
> ptrdiff_t it_charpos;
>
> w->optional_new_start =3D false;
>
> This code should set the w->force_start flag. Does it? If not, what
> prevents that?
>
> Next, we have this:
>
> force_start:
>
> /* Handle case where place to start displaying has been specified,
> unless the specified location is outside the accessible range. */
> if (w->force_start)
> {
>
> The code after this tries to use the specified window-start point, and
> the question is: why it eventually rejects it (as what you see seems
> to suggest)?
>
> HTH
>
> P.S. It could be that the problem is entirely elsewhere, so don't be
> surprised if you step through all of that code and find that Emacs
> does indeed succeed to use the window-start point the scenario expects
> it to use.
Thanks for the guidance. Here is the gdb session transcript produced
for the test configuration where the first and third invocations of
`redisplay' are commented out and only the second invocation is
executed, with the result that, in all tests I've made with this
configuration, the loop stops immediately after one iteration (one test
series) with the message "window-start=3D671, point-max=3D793 in run 1" an=
d
the same display as after the loop stops when moving the mouse over the
frame, i.e. a case of "unexpected recentering":
steve [ ~/build/emacs-master/src ]$ gdb ./emacs
GNU gdb (GDB) 15.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.ht=
ml>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./emacs...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from t=
erminal]
DISPLAY =3D :0.0
TERM =3D dumb
Breakpoint 1 at 0x14f8d1: file /home/steve/src/emacs/emacs-master/src/emac=
s.c, line 424.
Breakpoint 2 at 0x113d4e: file /home/steve/src/emacs/emacs-master/src/xter=
m.c, line 27089.
(gdb) break window.c:7172
Breakpoint 3 at 0xbc850: file /home/steve/src/emacs/emacs-master/src/windo=
w.c, line 7172.
(gdb) break xdisp.c:20269
Breakpoint 4 at 0x5555555f90c6: file /home/steve/src/emacs/emacs-master/sr=
c/xdisp.c, line 20269.
(gdb) run -Q -l ~/comp/Emacs/bug#76186.el
Starting program: /home/steve/build/emacs-master/src/emacs -Q -l ~/comp/Em=
acs/bug#76186.el
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffdffd86c0 (LWP 16527)]
[New Thread 0x7fffdf6486c0 (LWP 16528)]
[New Thread 0x7fffdecb86c0 (LWP 16529)]
[New Thread 0x7fffde1706c0 (LWP 16530)]
[New Thread 0x7fffdd7366c0 (LWP 16531)]
Thread 1 "emacs" hit Breakpoint 3, Frecenter (arg=3D<optimized out>,
redisplay=3D<optimized out>)
at /home/steve/src/emacs/emacs-master/src/window.c:7172
7172 set_marker_both (w->start, w->contents, charpos, bytepos);
(gdb) n
7178 w->vscroll =3D 0;
(gdb) p w->start
$2 =3D XIL(0x555555d2419d)
(gdb) pr $2
[Thread 0x7fffde1706c0 (LWP 16530) exited]
#<marker at 793 in sample>
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=3DXIL(0x555555=
cdd175),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:20269
20269 if ((w->optional_new_start || window_frozen_p (w))
(gdb) n
20275 w->optional_new_start =3D false;
(gdb) p w->force_start
$3 =3D false
(gdb) n
20276 if (!w->force_start)
(gdb)
20278 start_display (&it, w, startp);
(gdb)
20279 move_it_to (&it, PT, 0, it.last_visible_y, -1,
(gdb)
20283 it_charpos =3D IT_CHARPOS (it);
(gdb)
20289 if (it.current_y =3D=3D 0 || line_bottom_y (&it) < it.last_visibl=
e_y)
(gdb)
20291 if (it_charpos =3D=3D PT)
(gdb)
20292 w->force_start =3D true;
(gdb) p w->force_start
$4 =3D false
(gdb) n
20309 if (!BASE_LINE_NUMBER_VALID_P (w))
(gdb) p w->force_start
$5 =3D true
(gdb) n
20317 if (w->force_start)
(gdb)
20322 w->force_start =3D false;
(gdb)
20327 if (!w->preserve_vscroll_p && !window_frozen_p (w))
(gdb)
20328 w->vscroll =3D 0;
(gdb)
20330 w->preserve_vscroll_p =3D false;
(gdb)
20331 w->window_end_valid =3D false;
(gdb)
20340 if (!update_mode_line
(gdb)
20348 if (CHARPOS (startp) < BEGV)
(gdb)
20350 else if (CHARPOS (startp) > ZV)
(gdb) p ZV
$6 =3D 793
(gdb) n
20355 if (!window_start_acceptable_p (window, CHARPOS (startp)))
(gdb) p CHARPOS (startp)
$7 =3D <optimized out>
(gdb) n
20363 clear_glyph_matrix (w->desired_matrix);
(gdb)
20364 if (!try_window (window, startp, 0))
(gdb)
20371 if (w->cursor.vpos < 0)
(gdb)
20403 if (!cursor_row_fully_visible_p (w, false, false, false))
(gdb)
20421 else if (w->cursor.vpos >=3D 0)
(gdb)
20426 int pixel_margin =3D margin * frame_line_height;
(gdb) p w->cursor.vpos
$8 =3D 0
(gdb) n
20427 bool tab_line =3D window_wants_tab_line (w);
(gdb)
20428 bool header_line =3D window_wants_header_line (w);
(gdb)
20434 if (w->cursor.vpos < margin + tab_line + header_line)
(gdb)
20442 int window_height =3D window_box_height (w);
(gdb)
20444 if (tab_line)
(gdb)
20446 if (header_line)
(gdb)
20448 if (w->cursor.y >=3D window_height - pixel_margin)
(gdb)
20459 if (new_vpos >=3D 0)
(gdb)
20502 if (w->cursor.vpos < 0
(gdb)
21017 SET_TEXT_POS_FROM_MARKER (startp, w->start);
(gdb) p startp
$9 =3D <optimized out>
(gdb) p w->start
$10 =3D XIL(0x555555d2419d)
(gdb) pr $10
#<marker at 793 in sample>
(gdb) n
21018 w->start_at_line_beg =3D (CHARPOS (startp) =3D=3D BEGV
(gdb)
21022 if ((update_mode_line
(gdb) p w->start_at_line_beg
$11 =3D true
(gdb) n
21040 specpdl_ref count1 =3D SPECPDL_INDEX ();
(gdb)
21042 specbind (Qinhibit_quit, Qt);
(gdb)
21043 display_mode_lines (w);
(gdb)
21044 unbind_to (count1, Qnil);
(gdb)
21048 if (window_wants_mode_line (w)
(gdb)
21059 if (window_wants_tab_line (w)
(gdb)
21070 if (window_wants_header_line (w)
(gdb)
21079 if (f->fonts_changed)
(gdb)
21083 if (!line_number_displayed && w->base_line_pos !=3D -1)
(gdb)
21093 if (update_mode_line
(gdb)
21098 if (FRAME_WINDOW_P (f))
(gdb)
21101 redisplay_menu_p =3D FRAME_EXTERNAL_MENU_BAR (f);
(gdb)
21109 if (redisplay_menu_p)
(gdb)
21110 display_menu_bar (w);
(gdb)
21113 if (FRAME_WINDOW_P (f))
(gdb)
21115 if (WINDOWP (f->tab_bar_window)
(gdb)
21122 if (FRAME_EXTERNAL_TOOL_BAR (f))
(gdb)
21123 update_frame_tool_bar (f);
(gdb)
21138 gui_consider_frame_title (w->frame);
(gdb)
21146 if (FRAME_WINDOW_P (f)
(gdb)
21164 if (WINDOW_BOTTOM_DIVIDER_WIDTH (w))
(gdb)
493 return XUNTAG (a, Lisp_Vectorlike, struct window);
(gdb)
1623 return frame_dimension (f->bottom_divider_width);
(gdb)
21176 if (WINDOW_HAS_VERTICAL_SCROLL_BAR (w) || WINDOW_HAS_HORIZONTAL_S=
CROLL_BAR (w))
(gdb)
21178 if (WINDOW_HAS_VERTICAL_SCROLL_BAR (w))
(gdb)
21180 set_vertical_scroll_bar (w);
(gdb)
21182 if (WINDOW_HAS_HORIZONTAL_SCROLL_BAR (w))
(gdb)
21188 if (FRAME_TERMINAL (f)->redeem_scroll_bar_hook)
(gdb)
21189 (*FRAME_TERMINAL (f)->redeem_scroll_bar_hook) (w);
(gdb)
21195 if (CHARPOS (opoint) < BEGV)
(gdb)
21197 else if (CHARPOS (opoint) > ZV)
(gdb)
21199 else if (ochars_modiff =3D=3D CHARS_MODIFF)
(gdb)
21200 TEMP_SET_PT_BOTH (CHARPOS (opoint), BYTEPOS (opoint));
(gdb)
21211 set_buffer_internal_1 (old);
(gdb)
21214 if (CHARPOS (lpoint) <=3D ZV)
(gdb)
21216 if (lchars_modiff =3D=3D CHARS_MODIFF)
(gdb)
21217 TEMP_SET_PT_BOTH (CHARPOS (lpoint), BYTEPOS (lpoint));
(gdb)
21222 unbind_to (count, Qnil);
(gdb)
redisplay_window_0 (window=3Dwindow@entry=3DXIL(0x555555cdd175))
at /home/steve/src/emacs/emacs-master/src/xdisp.c:18126
18126 return Qnil;
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=3DXIL(0x555555=
cdd175),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:20269
20269 if ((w->optional_new_start || window_frozen_p (w))
(gdb) n
20309 if (!BASE_LINE_NUMBER_VALID_P (w))
(gdb) p w->force_start
$12 =3D false
(gdb) n
20311 w->base_line_number =3D 0;
(gdb)
20317 if (w->force_start)
(gdb)
20520 if (current_matrix_up_to_date_p
(gdb)
20540 else if (w->start_at_line_beg
(gdb)
20556 else if ((tem =3D try_window_id (w)) !=3D 0)
(gdb)
20570 else if (CHARPOS (startp) >=3D BEGV
(gdb)
20677 if (!update_mode_line)
(gdb)
20684 if ((0 < scroll_conservatively
(gdb)
20732 init_iterator (&it, w, PT, PT_BYTE, NULL, DEFAULT_FACE_ID);
(gdb)
20733 it.current_y =3D it.last_visible_y;
(gdb)
20734 if (centering_position < 0)
(gdb)
20736 ptrdiff_t margin_pos =3D CHARPOS (startp);
(gdb)
20742 if (margin
(gdb)
20760 scrolling_up =3D PT > margin_pos;
(gdb)
20761 aggressive =3D
(gdb)
20766 if (!MINI_WINDOW_P (w)
(gdb)
20805 centering_position =3D window_box_height (w) / 2;
(gdb)
20807 if (current_buffer->long_line_optimizations_p
(gdb)
20820 move_it_vertically_backward (&it, centering_position);
(gdb)
20829 if (it.current_y <=3D 0)
(gdb)
20836 it.current_x =3D it.wrap_prefix_width =3D it.hpos =3D 0;
(gdb)
20841 set_marker_both (w->start, Qnil, IT_CHARPOS (it), IT_BYTEPOS (it))=
;
(gdb)
20844 startp =3D run_window_scroll_functions (window, it.current.pos);
(gdb)
20849 itdata =3D bidi_shelve_cache ();
(gdb)
20853 if (!current_matrix_up_to_date_p
(gdb)
20863 use_desired_matrix =3D (try_window (window, startp, 0) =3D=3D 1)=
;
(gdb)
20865 bidi_unshelve_cache (itdata, false);
(gdb)
20870 if (f->fonts_changed)
(gdb)
20878 if (w->cursor.vpos < 0)
(gdb)
20924 if (w->cursor.vpos < 0)
(gdb)
20977 if (!cursor_row_fully_visible_p (w, false, false, false))
(gdb)
21017 SET_TEXT_POS_FROM_MARKER (startp, w->start);
(gdb)
21018 w->start_at_line_beg =3D (CHARPOS (startp) =3D=3D BEGV
(gdb) p w->start
$13 =3D XIL(0x555555d2419d)
(gdb) pr $13
#<marker at 671 in sample>
(gdb) p ZV
$14 =3D 793
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=3DXIL(0x555555=
cdd175),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:20269
20269 if ((w->optional_new_start || window_frozen_p (w))
(gdb) c
Continuing.
Thread 1 "emacs" hit Breakpoint 4, redisplay_window (window=3DXIL(0x555555=
cdd175),
just_this_one_p=3Djust_this_one_p@entry=3Dfalse)
at /home/steve/src/emacs/emacs-master/src/xdisp.c:20269
20269 if ((w->optional_new_start || window_frozen_p (w))
(gdb) c
Continuing.
Thread 1 "emacs" received signal SIGPIPE, Broken pipe.
0x00007ffff31407ef in __GI___libc_write (fd=3D13, buf=3D0x555555d07070, nb=
ytes=3D568)
at ../sysdeps/unix/sysv/linux/write.c:26
warning: 26 ../sysdeps/unix/sysv/linux/write.c: No such file or directory
(gdb)
Continuing.
[Thread 0x7fffdd7366c0 (LWP 16531) exited]
[Thread 0x7fffdf6486c0 (LWP 16528) exited]
[Thread 0x7fffdffd86c0 (LWP 16527) exited]
[Thread 0x7fffefe110c0 (LWP 16526) exited]
[Thread 0x7fffdecb86c0 (LWP 16529) exited]
[New process 16526]
[Inferior 1 (process 16526) exited normally]
(gdb)
As you can see, after hitting the window.c breakpoint and stepping over
set_marker_both, window-start is at 793, i.e. point-max, which is the
expected position after invoking `(recenter 0)'. After continuing and
hitting the xdisp.c breakpoint, I stepped through the code and saw
w->force_start get set to true, then stepped further until
redisplay_window_0, then continued and hit the breakpoint again, and now
w->force_start was false. Then I stepped further until
SET_TEXT_POS_FROM_MARKER (startp, w->start), after which window-start
was now at 671, the value displayed in the message after one iteration,
indicating the unexpected recentering. I cannot tell what caused
window-start to change from 793 to 671.
Steve Berman
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 22 Feb 2025 14:05:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 22 09:05:38 2025
Received: from localhost ([127.0.0.1]:51944 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tlq8Q-00028Q-8p
for submit <at> debbugs.gnu.org; Sat, 22 Feb 2025 09:05:38 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:35118)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tlq8M-000277-Lw
for 76186 <at> debbugs.gnu.org; Sat, 22 Feb 2025 09:05: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 1tlq8G-0000FH-7J; Sat, 22 Feb 2025 09:05:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=8N1/irJ+UDQEKggDtu2TIjQ/1bhzRtCPLQ8RsbcO6TI=; b=X11O5nbjMlPG
XAMnytuzSR3iDwO6faLgiPDzZxcD4JJLS1mxNGogPT4xa4czDi1V4AqtKawzAD53ZNWRbMkCG58CV
sGVGnCnmC33J+VRWChSlOwieBcWSUoNr77gDcMHJS5l9vYga9KV/RneuLDV3kRu50xdaCZA8OBABF
ip2rIg1wnog1H10VAohJ9qwf91aUSdJ03RMXcKjbsWnfC6v5z4IONn+mau4borm3JAZfPt+lCZymx
7eHt95ZcRpRg8VWLipiU9VnYX+zov9d3yYwaMILgKzqMlLUA7cwnWGl//uxL81E9D6SKyDp3HZAQM
Og+G3zWHgH66v8rRZKcMZw==;
Date: Sat, 22 Feb 2025 16:05:19 +0200
Message-Id: <86wmdihy74.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stephen Berman <stephen.berman@HIDDEN>
In-Reply-To: <87wmdi9jnp.fsf@HIDDEN> (message from Stephen Berman on Sat, 22
Feb 2025 14:46:34 +0100)
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
expected
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN>
<86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN>
<8634g6jeab.fsf@HIDDEN> <87wmdi9jnp.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76186
Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN
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: Stephen Berman <stephen.berman@HIDDEN>
> Cc: triska@HIDDEN, 76186 <at> debbugs.gnu.org
> Date: Sat, 22 Feb 2025 14:46:34 +0100
>
> On Sat, 22 Feb 2025 15:32:28 +0200 Eli Zaretskii <eliz@HIDDEN> wrote:
>
> > Thanks. I'm afraid I'm none the wiser, because I see none of the
> > phenomena you describe on my system. Whatever I do, the test always
> > runs to completion, and the last screen shows point at EOB.
>
> By "runs to completion" I suppose you mean 501 iterations (or whatever
> you set n to)?
Yes.
> In this case is the message as above, with window-start
> and point-max identical, or does the message show them differing?
The former.
> The latter would be unexpected unless the loop stopped before 501
> (or n) iterations.
I don't see that.
> > Some parts of what you describe seem to indicate that the problem is
> > not with 'recenter' itself, but with the following redisplay cycle,
> > which, for some reason, considers the window-start position
> > inappropriate and recenters point on display. But I have no idea why,
> > and it is impossible to debug this when the problem happens as part of
> > 500 iterations.
>
> I agree, and the apparent ineffectiveness of Edebug in this case is also
> frustrating. I could try using gdb with the test configuration where I
> consistly get the "unexpected recentering" after one iteration; can you
> suggest where to set the break point and any other input that may be
> helpful?
'recenter' takes effect in two parts: first Emacs determines where to
put window-start, and then redisplay redraws the window according to
that.
The first part is in window.c, in Frecenter, where we have this:
/* Set the new window start. */
set_marker_both (w->start, w->contents, charpos, bytepos);
So first we should determine whether this code determines the
window-start point as expected. If not, the reason is inside the
implementation of 'recenter'.
The second part is in xdisp.c:redisplay_window, where it attempts to
obey the optional_new_start flag of the window. It starts here:
/* If someone specified a new starting point but did not insist,
check whether it can be used. */
if ((w->optional_new_start || window_frozen_p (w))
&& CHARPOS (startp) >= BEGV
&& CHARPOS (startp) <= ZV)
{
ptrdiff_t it_charpos;
w->optional_new_start = false;
This code should set the w->force_start flag. Does it? If not, what
prevents that?
Next, we have this:
force_start:
/* Handle case where place to start displaying has been specified,
unless the specified location is outside the accessible range. */
if (w->force_start)
{
The code after this tries to use the specified window-start point, and
the question is: why it eventually rejects it (as what you see seems
to suggest)?
HTH
P.S. It could be that the problem is entirely elsewhere, so don't be
surprised if you step through all of that code and find that Emacs
does indeed succeed to use the window-start point the scenario expects
it to use.
Thanks.
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 22 Feb 2025 13:46:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 22 08:46:49 2025 Received: from localhost ([127.0.0.1]:51618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tlpqC-0007h4-PN for submit <at> debbugs.gnu.org; Sat, 22 Feb 2025 08:46:49 -0500 Received: from mout.gmx.net ([212.227.17.20]:56341) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <stephen.berman@HIDDEN>) id 1tlpqA-0007gE-7T for 76186 <at> debbugs.gnu.org; Sat, 22 Feb 2025 08:46:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1740231995; x=1740836795; i=stephen.berman@HIDDEN; bh=dcZ/YSe9hpIpoCNq+eXtGbHGyF7WNQ94yLn5lgTRdus=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=ZEPKCqNeoX+7jWfXeYerjtFpn24JGln9P/BphiG6fntQ3fIUEGo+w9enVPmjRgy3 a+e8egsUOzBMZgbajQkZYq4svzqJJBsJEStg2/a3AqlM4SuV73FYbo4dgSaWBA8C7 /QH8itWultGvvAHexZFGTq9FHt2K3EPdfepDRVxYSCqZgaaxhylierVOxe5uT7ybB ewbuAOwyitQs5uT08Voh753+x1iIhIyveFuCUUrVcbjKZWg1fH8kJtpMwyOg8WUzL MXMqXYB9FdzFav9Y+kkScfUj/TTexTnrl2f6DYacDHENJgPXQHKWqfxBozELDp9iO US0CTscFcE9pmpaG6A== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from strobelfssd ([88.130.50.215]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MfYPY-1t5tND1jC4-00kFB8; Sat, 22 Feb 2025 14:46:35 +0100 From: Stephen Berman <stephen.berman@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected In-Reply-To: <8634g6jeab.fsf@HIDDEN> References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN> <86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN> <8634g6jeab.fsf@HIDDEN> Date: Sat, 22 Feb 2025 14:46:34 +0100 Message-ID: <87wmdi9jnp.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:owvXpIVo9H8Z+j9pY9qT+rDWLdciqUuwuxE+jXfNJLF/WELhdAO 8CiVItfifz09suXVaoueqVCQ+kmyIICvz4eMEZ6UTTrVYAbXW141muIYSVIbGwMstx3RuLp h0LborQ/EOi7FRB/EUWDbkdKBubZKdSmmJkSnuAj0WIxScDosz0wjxfeJa0XnWtiffC0HWv IYx8WeQWFlm3RYKQSXmzg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:SUUyqztaokI=;i3FhGyOLQAyrMccP6bJ+oysyWOu S2SkBNeSSLytyRXjf/RygLFvArUwQm5UqMoqMViVKArbZv6EgIZK2CqNUvtmw2epglrtOO+rv BijlwRpgQS2Sr9Ik/BOzfg7St49VYpsOp3o4V6LyIGFbY3vY3n2IbwHQwaTsnk+P4TEVDgYcL ZU60EedLgS/+MZus2FCKOgmSbtAzi7yzFHf+uMyxq7RZSPXsvssEpH3NuLEUTQBFVWTnHps2W 9MQoD+7cQXKj/ZJulxLzfjWa6p+f/fNEOB8UOajh8rm0JOBVDhNvUVlstCvwj6ShJeTYrzbdk qIE/SW7f1NDnPME4IUsxvrDjko4tEpXGY5nzjaEQSiwtW+RoMxSIcZTxHpMDNj0PpMzKL9TPS VpmP6gYdf3NgbX4pxwnP6Vqj9afPGQjCvqBnuS5q7cfWatioHKnYS9/v9HfTOPlycAQI8jfbl ijFJfATMEFFX3ndOKzC/WPaan6vVYE8gROYhvmBmDpFngdH/kxbh4qtnCt89jz8N3th3WDLvS /M/QX1MewlGsKeRAhDZ7941Mz2qHxZD/HQnbRguhyqrMUAQFuB7BSexwCFRjjenThiDIaszu+ GanQADu17QK2i+UDJZWqhCN0UcgxzT6akfuTATMsXGmgaWGDDLEH2umnHcmWpmRDm/bYlUQ1c bzXuSA2yt9pMueOogP+OfLJ0wL4XB6SiL6d2sxY+M+YqiZiZZ7A/xR75zpJNlFoCecXgnuofy Z+KpUJoVTBRZCKDZ0X0RZpxCvL7sobWs7dzWa5f7SAAxEuv2T4gw2L+lMVuug6XhjpKqMbjsI cF0NgQPNR3iNt+Zu3cWD4FGHYUSjzOEV3ARz/+sw1cYk16u2JQ58sKLMOt3fb3Mm9tgnWd3dA hh66WsSrP5IVZ2EX4Jv8VNol/ivyEvNBm2sxwN5/CSaOCOcyzmv5osLJT+OpUOGvmg+HvYUqk S+wGorpJ/LtHTtlAHHnIGT7yUa+nqnmj150EVDU7wS4mwbMM1G3IN2Z46axnqoOm6j02hH5zj Da+z2VThP5DkXQNGq2nimL8nTabplVxgwrUJUct8LIB3VmLlFokYIlgwOzY0Mqoo+mouMgrlI VleQDz6MoHQ5edhnNWv1fg27T26zlZIR80872TPH1nh9hglLs/xlmpNzUutuAQrlhx7t6B4Id 4HOkPW6YznTI7BVmeh4tNllKRFj1NKye/huGR6zidT22qPkF/AHErTBUfjUyPPkDccmlQsAfh fdLe8tLQcNXKLNfgrapQ3dkhd/8pO8u+spHzZd+/m+1AkbWTBsiJCoQEYT8GE+jxZujmkeVB+ oYi329ZasQ+NOfMTRRlZW8poD5/bGl6mhgNixxsyv6Y38kgPIlrup9zRQr9yUeV95iy7mYgH1 dIF4aG6ZBHKK3L7/839T/Dav0+coDkzUjD8obtF40Awx3tl8Pya3/SisnHnQRMKgqSFwmqoZB Sh+7+Hg== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76186 Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN 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 (-) On Sat, 22 Feb 2025 15:32:28 +0200 Eli Zaretskii <eliz@HIDDEN> wrote: >> From: Stephen Berman <stephen.berman@HIDDEN> >> Cc: triska@HIDDEN, 76186 <at> debbugs.gnu.org >> Date: Sat, 22 Feb 2025 14:08:07 +0100 [...] >> When I start Emacs like this: >> >> emacs -Q -l bug#76186.el >> >> and, if the mouse pointer is over the Emacs frame, do not touch the >> mouse, then after 501 iterations the loop stops (I've also done tests >> with more than 10000 iterations with the same results) and the message >> "window-start=3D793, point-max=3D793 in run 501" is displayed, indicati= ng >> the expected result of `(recenter 0)'. However, in the displayed >> "sample" buffer, point-max is vertically centered in the window (as >> after `(recenter)') and window-start is 671. [...] > Thanks. I'm afraid I'm none the wiser, because I see none of the > phenomena you describe on my system. Whatever I do, the test always > runs to completion, and the last screen shows point at EOB. By "runs to completion" I suppose you mean 501 iterations (or whatever you set n to)? In this case is the message as above, with window-start and point-max identical, or does the message show them differing? The latter would be unexpected unless the loop stopped before 501 (or n) iterations. > Some parts of what you describe seem to indicate that the problem is > not with 'recenter' itself, but with the following redisplay cycle, > which, for some reason, considers the window-start position > inappropriate and recenters point on display. But I have no idea why, > and it is impossible to debug this when the problem happens as part of > 500 iterations. I agree, and the apparent ineffectiveness of Edebug in this case is also frustrating. I could try using gdb with the test configuration where I consistly get the "unexpected recentering" after one iteration; can you suggest where to set the break point and any other input that may be helpful? Steve Berman
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 22 Feb 2025 13:33:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 22 08:33:04 2025
Received: from localhost ([127.0.0.1]:51406 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tlpcr-0005YV-2m
for submit <at> debbugs.gnu.org; Sat, 22 Feb 2025 08:33:04 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:37072)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tlpco-0005XI-0E
for 76186 <at> debbugs.gnu.org; Sat, 22 Feb 2025 08:32:58 -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 1tlpcg-0004nq-Hy; Sat, 22 Feb 2025 08:32:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=qnG7pzWjzvEvyDaIYuekf7o3KRqDjOiQ67TmqEaXmUI=; b=Ywn0r38H8zr3
nwMnU9002O4uPDHx/+G+dROlZSmDbeOGhqWYRhLBqAiNZ5PWNqGLyZ8IRbqMK5zZXfF7jHyyFtreK
695KAy6JMuOUNCKxNcBQp5T7GK3AETYGE33Y9UwtoQguXVQa9bW4Xnb/W3TdV7ytkm2ucF9qJXtFP
Q/q147zMb3vktCSafUUeesHqwhZBHFgVcI8tUR5qZD0MQff27es78girpSTP9JowNUpuQFrmDJARa
Aq3CwktlvPL2sDS+TmoZSyWqIWr/jqBwTgs00Bef5XwtzEi2H9KRfdY0ACcxqIIGsIuextZI6KUYK
QN7ZhnI0csrWKkolD3hOiQ==;
Date: Sat, 22 Feb 2025 15:32:28 +0200
Message-Id: <8634g6jeab.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stephen Berman <stephen.berman@HIDDEN>
In-Reply-To: <871pvqb008.fsf@HIDDEN> (message from Stephen Berman on Sat, 22
Feb 2025 14:08:07 +0100)
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
expected
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN>
<86frkijr22.fsf@HIDDEN> <871pvqb008.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 76186
Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN
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: Stephen Berman <stephen.berman@HIDDEN>
> Cc: triska@HIDDEN, 76186 <at> debbugs.gnu.org
> Date: Sat, 22 Feb 2025 14:08:07 +0100
>
> > If you can investigate the situation where it happens and describe
> > what goes on there, or maybe even suggest what to do about that, it
> > will be very appreciated. Failing that, I hope that you could at
> > least answer the questions I posted about what is special in the
> > situation where it does happen. If you can show a simple recipe that
> > demonstrates the issue without looping endlessly, it will also help.
>
> In the attached file, I've refactored the second code snippet Markus
> posted into a single command, which facilitated experimenting with it.
> The following is a summary of my observations from experimenting with
> the code. I don't know how useful such impressions are, but that's the
> best I could come up with (I tried using Edebug but it alters the
> display configuration so I could not get the same test results).
>
> First, I found that I can reproduce the unexpected recentering without
> disabling the menu bar, tool bar and scroll bar, and using the default
> frame height and width as well as the default font specification.
> Moreover, AFAICT the dimensions and placement of the child frame, and
> whether the buffer displayed in the child frame has text, are
> irrelevant. (In the attached file the corresponding lines of code are
> all commented out.) However, I cannot reproduce the unexpected
> recentering without having a child frame nor without either a loop or
> manual iteration -- but sometimes only a single iteration suffices (more
> on that below).
>
> When I start Emacs like this:
>
> emacs -Q -l bug#76186.el
>
> and, if the mouse pointer is over the Emacs frame, do not touch the
> mouse, then after 501 iterations the loop stops (I've also done tests
> with more than 10000 iterations with the same results) and the message
> "window-start=793, point-max=793 in run 501" is displayed, indicating
> the expected result of `(recenter 0)'. However, in the displayed
> "sample" buffer, point-max is vertically centered in the window (as
> after `(recenter)') and window-start is 671.
>
> If I restart Emacs as above and while the loop is running continuously
> move the mouse over the frame, I see multiple messages
> "window-start=671, point-max=793 in run <N>", indicating the unexpected
> recentering, and then a new series of test runs commences. I
> implemented a condition to stop looping when the unexpected recentering
> happens on the first iteration (i.e., when N=1), and in all my tests
> when moving the mouse over the frame this condition is satisfied at some
> point. The display of the buffer is as above (i.e., as expected when
> window-start differs from point-max). (I tried to programmatically
> emulate moving the mouse over the frame with the help of
> `set-mouse-position' and `set-mouse-pixel-position', but in both cases
> the results were as in the first test without moving the mouse over the
> frame. I noticed that when I manually move the mouse over the frame,
> the pointer has the shape of an arrow, while with
> set-mouse-{pixel-}position the pointer is an "I-beam".)
>
> If I uncomment the third invocation of `redisplay' in the attached file
> and restart Emacs as above and do not move the mouse over the frame, the
> result, and the display, on stopping after 501 iterations is as
> described above. However, if I then type `M-x sometimes-not-recentering
> RET' and again do not move the mouse over the frame, then on stopping
> after 501 iterations the same message "window-start=793, point-max=793
> in run 501" is shown but now the buffer display fits the message: point
> is at the top left of the window. Repeating `M-x
> sometimes-not-recentering RET' gives the same result and display, though
> sometimes there is also a series of test runs (< 501) showing
> window-point and point-max differing, but then the next (automatically
> started) series ends after 501 iterations with these again identical and
> point displayed at top left in the window. However, this test
> configuration appears to be unstable: sometimes on starting Emacs as
> above I have gotten the result I get when moving the mouse over the
> frame, but this appears to be rare and unpredictable.
>
> If I again comment out the third invocation of `redisplay' and also
> comment out the first invocation (thus only the second invocation is
> executed), then on starting Emacs as above, in all tests I've made with
> this configuration the loop stops immediately after one iteration (one
> test series) with the message "window-start=671, point-max=793 in run 1"
> and the same display as after the loop stops when moving the mouse over
> the frame. If I then type `M-x sometimes-not-recentering RET', the
> result and display are the same, sometimes immediately after one
> iteration, sometimes after several series of test runs.
>
> If I leave the first and third invocations of `redisplay' commented out
> and also comment out the invocation of `sometimes-not-recentering' at
> the bottom of the file, and then start Emacs as above and type `M-x
> sometimes-not-recentering RET', then the results and display are
> invariably with window-point and point-max differing, but, unlike on all
> my tests when the command is executed on loading the file, this
> sometimes but not always happens after one test series of one iteration.
Thanks. I'm afraid I'm none the wiser, because I see none of the
phenomena you describe on my system. Whatever I do, the test always
runs to completion, and the last screen shows point at EOB.
Some parts of what you describe seem to indicate that the problem is
not with 'recenter' itself, but with the following redisplay cycle,
which, for some reason, considers the window-start position
inappropriate and recenters point on display. But I have no idea why,
and it is impossible to debug this when the problem happens as part of
500 iterations.
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 22 Feb 2025 13:08:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 22 08:08:27 2025
Received: from localhost ([127.0.0.1]:50999 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tlpF3-0001s0-Kb
for submit <at> debbugs.gnu.org; Sat, 22 Feb 2025 08:08:26 -0500
Received: from mout.gmx.net ([212.227.15.15]:59207)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <stephen.berman@HIDDEN>)
id 1tlpEy-0001qX-6z
for 76186 <at> debbugs.gnu.org; Sat, 22 Feb 2025 08:08:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net;
s=s31663417; t=1740229691; x=1740834491; i=stephen.berman@HIDDEN;
bh=4P8E1MhyzN+/c0pQ60ObloSKt6GiXaHODKnEeFFJ+48=;
h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date:
Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=gU9cEggG5vkmoDJoJs7/fCLfv0fOxLmcNk5be9IoWamKEvOoqyUCdlAFByUW5iHh
d/nyRRzrEZLSM7lnF4hX1tVb3trvUXhninSQqoFNKzIlt2jwGffgcAi7PT0XF6weK
tMUhnqihkIwEoSQ2O+KC8Hdk4hsasLz6OioRRpmos0HvUU+nvKZmXTKeIlRg9XKGw
WhZtLuRtEF2OoylJMFUbIrwyFsu/Rvt93jdTmKiv2UooDlNUNAaqugBSymh5dj15/
zG12sfIfVyuj8dQIotr4HndnsIkYkS4WfiKdUX2F0d3zBElI1qvqQeEhRV86ZBYIb
h3AAvHNHZ8J437vc5A==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfssd ([88.130.50.215]) by mail.gmx.net (mrgmx005
[212.227.17.190]) with ESMTPSA (Nemesis) id 1MhU5R-1t8O0u25Eh-00bpyH; Sat, 22
Feb 2025 14:08:11 +0100
From: Stephen Berman <stephen.berman@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as
expected
In-Reply-To: <86frkijr22.fsf@HIDDEN>
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN>
<86frkijr22.fsf@HIDDEN>
Date: Sat, 22 Feb 2025 14:08:07 +0100
Message-ID: <871pvqb008.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Provags-ID: V03:K1:vHg8Rc1mmjg4RhuleKThORgE2F4oRGtjLzYzGJBfo/XkbzCdrY9
WmmwjwnrUUd3gvXSgPvdx7jLr3qGsL6rrtP3l8ScHuHzLe892DLDHMRvd2cQUZFsSs1rvFh
6or+9oseSeTQOrF7cMZ4Sx+IICayfFfaCPzb6iwEpK0ynI6mvuSb9ZJX6U8+IIv+k9LO38h
fe9jf5GdipeUeGFUkXeDw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:JASDu9NzZso=;Kr8zhFxHpK0Ekog9sieu0DGFUBE
Vskawp4nK/mk7JeRYGgG1IlQ7KCUyKdHs9BJhFntuwzxV3bxIOYRnyN3X6PKhnr/gtTD++VSX
18Ws9RtHnoz4iVmAhr4Nxc2Lzd9PCOyZzmR8B9jzmwRwWJFhCvtr6tg3k159saT3Ua1r08opr
jyShRmthEZPJX7Bg73yJr+ZP4dEs+DHO0v/BL9cKlw5Q2B9hXNjMI/WPyPhaXQiv4jN73w24J
kNPSi+aDE3Pu89wA6vTLpwt7VU1y5QH/pCfl1qhUFfzCLyNHYycFW88nxSPT8/soz71ZmPZTw
+zPGXjJD3k8zuy/8LKpFrHhFv+wsMmX07oCo/g5JPHKfO5naZbeXn70iprK5F9gT8fe5iG9MA
1NZzDRTRgdwkCqeJV7fLCVbMhUJnLgIDJkm8Xgm1fnjyu/zXDQ0lA6/3ENo5HsgpiCGvQjeXj
1y1h6MRs6t02afWBaP/WL5YO550hKGCEVHpogVKKBvZ33MEOAAvpf2PT1+Pv0jT4m7hlWgyMZ
RVaLZeUQodpgKFpxpa/Le8xm0ksDzaxqs+GZwI9wd6GSLgEMiZf7ZI1mxp6jl/BtAA2hm/WTo
eLpylJCW/3xdi4qu+Jmx5vQsLYsnfKEJlpsilZ7apqmSijtmD8PQ3as3eaHwzav3z8HD1jvuS
BfAGhe56aD7IWq2fJOiPA4mRllRht/EVrfmHOna/XU6eY/cpbf291gLAGT206YBcetpUx9B8B
BwWNJ2udsmBGfYXabXJuiEfrZw3WDgMz0KwSp5E3gwbiBFzkKsD8CMO5MQj2B/6oVqWIbrM7E
FIgfsOj0lz9L5APqlokPHxs62wetJR9s+Pm+iKzWhH5vhaINQo02i/9qFHSocTjcqFtSkYj7y
TpORA5mQ4qhHbXz4Cm4+zY7dF6B4u+6bR5b2Y2qCNbizWCExhS1+HeZHkkkgAaW9rYBfrxfSy
9+23BKfitdIXTC88oi+VnsYnWCuG8ziT6Evha0fN84O0LlfqGez8przWzBu44Ko1n2upqIuG4
xS2bDS8/lErVWR+GusoXpcfl+r1Ohv32Jem2kpdwddx4OPpxRT9EBix0om4RjwjJMu1IQKuVq
NiVKLulXMGb4tFWntONW0I089iXjK99o0YFIo1enLn7DVKKzgJlxPKZCwTM29CqjQ8coZt/el
pBQl1MWONPCDlEZamBXvVm38PZ+3rVv84r/bP812rWBECcFS1oAC9pmL3uWDDOr9OHphvMp3w
/zpMYXzx7n2abJBo7M4vHpvP6i0Q2CZpTVcrQR8ysEFhuLvUA/Pczc92pyynnagBL1axUqB0a
Do03X0/Bhzf2DVr1qMyf1lc4km6gpFZBef/voEMXgX2H10nioxQz7HI4WoJezdx/Gwnu78xZ1
MLfBgB5V7CSQol2l5VuMmJYWmcqyaIOMJ5VxWarJZppr50aFk0eHPlH6eoO5KhfVcIBLUsMUl
oKFC9aA==
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 76186
Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN
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 (-)
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Thu, 13 Feb 2025 08:29:25 +0200 Eli Zaretskii <eliz@HIDDEN> wrote:
>> From: Stephen Berman <stephen.berman@HIDDEN>
>> Cc: Eli Zaretskii <eliz@HIDDEN>, 76186 <at> debbugs.gnu.org
>> Date: Wed, 12 Feb 2025 22:53:52 +0100
>>
>> I can reproduce the issue, both with the original code snippet and the
>> current one, on this system:
>>
>> GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>> 3.24.43, cairo version 1.18.2) of 2025-02-06 built on strobelfssd
>> Repository revision: ea04dd8ca93d609c0ee475c4acf58a56dfc0f1f3
>> Repository branch: master
>> Windowing system distributor 'The X.Org Foundation', version 11.0.12101=
013
>> System Description: Linux From Scratch r12.2-17-systemd
>>
>> Configured using:
>> 'configure -C 'CFLAGS=3D-Og -g3' PKG_CONFIG_PATH=3D/opt/qt6/lib/pkgcon=
fig'
>>
>> I haven't tried to debug it and don't really have a good idea how to
>> proceed with that, but I'll be happy to try any suggestions. However, =
I
>> will be traveling for about a week and won't be able to do that till th=
e
>> end of next week at the earliest.
>
> Thanks.
>
> If you can investigate the situation where it happens and describe
> what goes on there, or maybe even suggest what to do about that, it
> will be very appreciated. Failing that, I hope that you could at
> least answer the questions I posted about what is special in the
> situation where it does happen. If you can show a simple recipe that
> demonstrates the issue without looping endlessly, it will also help.
In the attached file, I've refactored the second code snippet Markus
posted into a single command, which facilitated experimenting with it.
The following is a summary of my observations from experimenting with
the code. I don't know how useful such impressions are, but that's the
best I could come up with (I tried using Edebug but it alters the
display configuration so I could not get the same test results).
First, I found that I can reproduce the unexpected recentering without
disabling the menu bar, tool bar and scroll bar, and using the default
frame height and width as well as the default font specification.
Moreover, AFAICT the dimensions and placement of the child frame, and
whether the buffer displayed in the child frame has text, are
irrelevant. (In the attached file the corresponding lines of code are
all commented out.) However, I cannot reproduce the unexpected
recentering without having a child frame nor without either a loop or
manual iteration -- but sometimes only a single iteration suffices (more
on that below).
When I start Emacs like this:
emacs -Q -l bug#76186.el
and, if the mouse pointer is over the Emacs frame, do not touch the
mouse, then after 501 iterations the loop stops (I've also done tests
with more than 10000 iterations with the same results) and the message
"window-start=3D793, point-max=3D793 in run 501" is displayed, indicating
the expected result of `(recenter 0)'. However, in the displayed
"sample" buffer, point-max is vertically centered in the window (as
after `(recenter)') and window-start is 671.
If I restart Emacs as above and while the loop is running continuously
move the mouse over the frame, I see multiple messages
"window-start=3D671, point-max=3D793 in run <N>", indicating the unexpecte=
d
recentering, and then a new series of test runs commences. I
implemented a condition to stop looping when the unexpected recentering
happens on the first iteration (i.e., when N=3D1), and in all my tests
when moving the mouse over the frame this condition is satisfied at some
point. The display of the buffer is as above (i.e., as expected when
window-start differs from point-max). (I tried to programmatically
emulate moving the mouse over the frame with the help of
`set-mouse-position' and `set-mouse-pixel-position', but in both cases
the results were as in the first test without moving the mouse over the
frame. I noticed that when I manually move the mouse over the frame,
the pointer has the shape of an arrow, while with
set-mouse-{pixel-}position the pointer is an "I-beam".)
If I uncomment the third invocation of `redisplay' in the attached file
and restart Emacs as above and do not move the mouse over the frame, the
result, and the display, on stopping after 501 iterations is as
described above. However, if I then type `M-x sometimes-not-recentering
RET' and again do not move the mouse over the frame, then on stopping
after 501 iterations the same message "window-start=3D793, point-max=3D793
in run 501" is shown but now the buffer display fits the message: point
is at the top left of the window. Repeating `M-x
sometimes-not-recentering RET' gives the same result and display, though
sometimes there is also a series of test runs (< 501) showing
window-point and point-max differing, but then the next (automatically
started) series ends after 501 iterations with these again identical and
point displayed at top left in the window. However, this test
configuration appears to be unstable: sometimes on starting Emacs as
above I have gotten the result I get when moving the mouse over the
frame, but this appears to be rare and unpredictable.
If I again comment out the third invocation of `redisplay' and also
comment out the first invocation (thus only the second invocation is
executed), then on starting Emacs as above, in all tests I've made with
this configuration the loop stops immediately after one iteration (one
test series) with the message "window-start=3D671, point-max=3D793 in run =
1"
and the same display as after the loop stops when moving the mouse over
the frame. If I then type `M-x sometimes-not-recentering RET', the
result and display are the same, sometimes immediately after one
iteration, sometimes after several series of test runs.
If I leave the first and third invocations of `redisplay' commented out
and also comment out the invocation of `sometimes-not-recentering' at
the bottom of the file, and then start Emacs as above and type `M-x
sometimes-not-recentering RET', then the results and display are
invariably with window-point and point-max differing, but, unlike on all
my tests when the command is executed on loading the file, this
sometimes but not always happens after one test series of one iteration.
Steve Berman
--=-=-=
Content-Type: application/emacs-lisp
Content-Disposition: attachment; filename=bug#76186.el
Content-Transfer-Encoding: quoted-printable
(defun sometimes-not-recentering ()
(interactive)
;; (menu-bar-mode 0)
;; (tool-bar-mode 0)
;; (scroll-bar-mode 0)
;; (set-frame-height nil 27)
;; (set-frame-width nil 102)
(let ((test-run 0))
(while (natnump test-run)
(setq test-run (1+ test-run))
(setq frame-title-format (format "Test run %d" test-run))
(let ((buf (get-buffer-create "sample")))
(switch-to-buffer buf)
;; (make-local-variable 'face-remapping-alist)
;; (setq face-remapping-alist '((default (:family "DejaVu Sans Mono"
;; :height 218))))
(erase-buffer)
(save-excursion
(dotimes (i 100)
(insert (format "line %d\n" i))))
(let ((frame (make-frame `((parent-frame . ,(selected-frame))
;; (left . 200)
;; (top . 200)
;; (width . (text-pixels . 100))
;; (height . (text-pixels . 100))
)))
;; (buf (get-buffer-create "buffer-in-frame"))
)
(with-selected-frame frame
(switch-to-buffer "bla")
;; (switch-to-buffer buf)
;; (erase-buffer)
;; (insert "Hello!")
)
;; (set-mouse-position (selected-frame) (random (frame-width))
;; (random (frame-height)))
;; (set-mouse-pixel-position (selected-frame) (random (frame-pixel-width=
))
;; (random (frame-pixel-height)))
(redisplay) ; redisplay 1
(delete-frame frame)
;; (kill-buffer buf)
(goto-char (point-max))
(insert "\n\n")
(recenter 0)
(redisplay) ; redisplay 2
(let* ((wst (window-start))
(pmx (point-max))
(msg (format "window-start=3D%d, point-max=3D%d in run %d"
wst pmx test-run)))
(if (=3D wst pmx)
(let ((n 500))
(when (> test-run n)
(message msg)
(setq test-run -1)))
(message msg)
(setq test-run (if (> test-run 1) 0 -1))))
;; (redisplay) ; redisplay 3
)))))
(sometimes-not-recentering)
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 13 Feb 2025 21:35:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 13 16:35:15 2025
Received: from localhost ([127.0.0.1]:45871 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tigra-0003Dh-Uv
for submit <at> debbugs.gnu.org; Thu, 13 Feb 2025 16:35:15 -0500
Received: from [78.47.144.35] (port=60066 helo=metalevel.at)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <triska@HIDDEN>) id 1tigrY-0003AJ-5a
for 76186 <at> debbugs.gnu.org; Thu, 13 Feb 2025 16:35:12 -0500
Received: by metalevel.at (Postfix, from userid 1000)
id 7BF519C773; Thu, 13 Feb 2025 22:35:10 +0100 (CET)
From: Markus Triska <triska@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#76186: 31.0.50;
(recenter 0) sometimes does not recenter as expected
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <86ikpejrcb.fsf@HIDDEN>
<87r041r83s.fsf@HIDDEN> <86cyflh8q4.fsf@HIDDEN>
Date: Thu, 13 Feb 2025 22:35:10 +0100
In-Reply-To: <86cyflh8q4.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 13 Feb
2025 22:48:19 +0200")
Message-ID: <87o6z5y1dd.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > Is position of
point-max
relative to the bottom of the window also the > same in the cases where this
happens and in those it doesn't? In all cases where I can elicit the issue,
point-max is at the same position relative to the bottom of the window, and
it is always on line 10 out of 17 fully visible lines in total.
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.47.144.35 listed in bl.score.senderscore.com]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.47.144.35 listed in sa-trusted.bondedsender.org]
0.0 SPF_NONE SPF: sender does not publish an SPF Record
1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Debbugs-Envelope-To: 76186
Cc: 76186 <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: 0.3 (/)
Eli Zaretskii <eliz@HIDDEN> writes:
> Is position of point-max relative to the bottom of the window also the
> same in the cases where this happens and in those it doesn't?
In all cases where I can elicit the issue, point-max is at the same
position relative to the bottom of the window, and it is always on line
10 out of 17 fully visible lines in total.
I have uploaded a screenshot that shows the situation when the issue arises:
https://www.metalevel.at/ei/recenter_sometimes_not_recentering.png
After each iteration of the loop, the expected situation is that the
cursor (which is then at point-max) is in the very first visible line of
the window, and that (window-start) is equal to (point-max), and that is
also what the code I posted tests at the end of each iteration. The
expected situation occurs in most iterations, but not in all iterations.
Sometimes the issue happens after 3000 or more iterations in which
recentering works as expected, and it sometimes also takes longer than
10 seconds of running the loop to elicit the issue.
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 13 Feb 2025 20:49:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 13 15:49:15 2025 Received: from localhost ([127.0.0.1]:45691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tig95-0000zv-A5 for submit <at> debbugs.gnu.org; Thu, 13 Feb 2025 15:49:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54798) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tig93-0000zQ-EE for 76186 <at> debbugs.gnu.org; Thu, 13 Feb 2025 15:49:13 -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 1tig8x-0008RA-AR; Thu, 13 Feb 2025 15:49:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Q8n3/b27NADCWXVhHokf6ayAAxLKH+wBWQx/37BPyGg=; b=Utr0BnG8oCgI Fj9l/xSMdRuKAWeubB4pK5C269gKjzyIhwEBER8Q9TO+ZPoRHVHqM2gDrN+rEfjnqsyhNQwHr8r+V kQAfzaaht6nq8W/VN4samC5sS3uOKD7yqp7gv/5jY9N0eKiKb3WOgDfz2+tCPIbdv+uzJVDO2/F0N 7qZMLf+qGO2pflGODdq6neu7EVCt1mz9VgOgOZzm06sSliqbUTrnbzXUveyHZkPN9iwTYI5JPeADE YW9JywtUXb16QFkgimcOodAC/6MfHPn0ho4Ocq0gqwDQgawuUe5Rn0XJjgsXgznkdbc8LQ6ojwr8E eARRoHHwcK57wkNhUDRc2A==; Date: Thu, 13 Feb 2025 22:48:19 +0200 Message-Id: <86cyflh8q4.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Markus Triska <triska@HIDDEN> In-Reply-To: <87r041r83s.fsf@HIDDEN> (message from Markus Triska on Thu, 13 Feb 2025 19:51:35 +0100) Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> <86ikpejrcb.fsf@HIDDEN> <87r041r83s.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76186 Cc: 76186 <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: Markus Triska <triska@HIDDEN> > Cc: 76186 <at> debbugs.gnu.org > Date: Thu, 13 Feb 2025 19:51:35 +0100 > > Considering a few key indicators, major preconditions of the cases where > it works as expected are exactly identical to the cases where it doesn't > work as expected: > > 0. the frame and window geometry are the same and not atypical, > the font is the same and the characters are only ASCII, > lines are not overly long and not truncated, no text properties > or overlays are used in the example I posted > 1. the buffer contents are the same in all cases > 2. point is always at (point-max) when (recenter 0) is invoked > 3. redispay is always called so that recentering can take effect. Is position of point-max relative to the bottom of the window also the same in the cases where this happens and in those it doesn't?
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 13 Feb 2025 18:51:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 13 13:51:39 2025
Received: from localhost ([127.0.0.1]:45468 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tieJG-0004Dp-Sx
for submit <at> debbugs.gnu.org; Thu, 13 Feb 2025 13:51:39 -0500
Received: from [78.47.144.35] (port=57968 helo=metalevel.at)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <triska@HIDDEN>) id 1tieJE-0004Dg-Qd
for 76186 <at> debbugs.gnu.org; Thu, 13 Feb 2025 13:51:37 -0500
Received: by metalevel.at (Postfix, from userid 1000)
id 905479C779; Thu, 13 Feb 2025 19:51:35 +0100 (CET)
From: Markus Triska <triska@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#76186: 31.0.50;
(recenter 0) sometimes does not recenter as expected
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
<87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN>
<87mseqeuox.fsf@HIDDEN> <86ikpejrcb.fsf@HIDDEN>
Date: Thu, 13 Feb 2025 19:51:35 +0100
In-Reply-To: <86ikpejrcb.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 13 Feb
2025 08:23:16 +0200")
Message-ID: <87r041r83s.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > What is special or
noteworthy about the cases where it doesn't work as > expected? Here is what
I found out so far regarding this key question:
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.47.144.35 listed in bl.score.senderscore.com]
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.47.144.35 listed in sa-trusted.bondedsender.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 SPF_NONE SPF: sender does not publish an SPF Record
1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Debbugs-Envelope-To: 76186
Cc: 76186 <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: 0.3 (/)
Eli Zaretskii <eliz@HIDDEN> writes:
> What is special or noteworthy about the cases where it doesn't work as
> expected?
Here is what I found out so far regarding this key question:
Considering a few key indicators, major preconditions of the cases where
it works as expected are exactly identical to the cases where it doesn't
work as expected:
0. the frame and window geometry are the same and not atypical,
the font is the same and the characters are only ASCII,
lines are not overly long and not truncated, no text properties
or overlays are used in the example I posted
1. the buffer contents are the same in all cases
2. point is always at (point-max) when (recenter 0) is invoked
3. redispay is always called so that recentering can take effect.
Yet, there is something that distinguishes the cases, because in some
cases the recentering works as expected, and in other (rare) cases it
doesn't work as expected even though points (0) to (3) are all the same.
For instance, the loop I posted keeps all these factors the same in each
iteration, yet throws an exception in some but not all iterations.
At one time I believed that undo-auto-current-boundary-timer, which runs
every 10 seconds, may play a role. However, the issue also arises on
both systems I tested even after I cancel the timer.
At another time, I believed that fontification plays a role, but I
eventually found that the issue also arises with font-lock-mode disabled,
and the example I posted does not use font-lock-mode.
I cannot elicit the issue if I remove the creation, modification and
deletion of the frame denoted by `frame' in the snippet I posted. This
could be an indication that the interaction of frames may play a role,
in such a way that some iterations behave differently than others even
though the factors mentioned above are exactly the same in all cases.
Thank you and all the best,
Markus
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 13 Feb 2025 06:29:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 13 01:29:38 2025 Received: from localhost ([127.0.0.1]:39710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tiSjC-00073a-FK for submit <at> debbugs.gnu.org; Thu, 13 Feb 2025 01:29:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34738) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tiSj7-000734-Uk for 76186 <at> debbugs.gnu.org; Thu, 13 Feb 2025 01:29:37 -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 1tiSj2-00088F-DI; Thu, 13 Feb 2025 01:29:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=XAtUdypTPG1Zl4Hq5wVPdN4R9G0OgXSoNz0OPXtrSxE=; b=ksstKGCzSBBf ntKEHN3/tXZMX1oRQHOcjdaf2shzPwmlLiAIQqY3T9ZfM0qqRuY5N6D1C7l6rZJLeWePKZWu36qyP LBZH1YSE01PiHsixAN62C4l0sMMptXT/cCFVueLoCSudvgRRlcH8oW+hyJ5QDgb9x55Ne+zCOTkn6 uzEoZ+1aYyimxLFNYA1fBfdmBH9tIzjvzgxZGnvt2IwKGzobu3hs2c3vnlzQfFW6YJ35ScDXmIZXZ AJ3RsAOObecaqIt/bteFdRdYGFGTaUArctY+axviSpoWcapvvQi0UsHAulI3lCgTWzFpO39P/nj3R 3aNElhi0669LbdwVnOXreQ==; Date: Thu, 13 Feb 2025 08:29:25 +0200 Message-Id: <86frkijr22.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stephen Berman <stephen.berman@HIDDEN> In-Reply-To: <87r042q173.fsf@HIDDEN> (message from Stephen Berman on Wed, 12 Feb 2025 22:53:52 +0100) Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76186 Cc: 76186 <at> debbugs.gnu.org, triska@HIDDEN 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: Stephen Berman <stephen.berman@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 76186 <at> debbugs.gnu.org > Date: Wed, 12 Feb 2025 22:53:52 +0100 > > I can reproduce the issue, both with the original code snippet and the > current one, on this system: > > GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version > 3.24.43, cairo version 1.18.2) of 2025-02-06 built on strobelfssd > Repository revision: ea04dd8ca93d609c0ee475c4acf58a56dfc0f1f3 > Repository branch: master > Windowing system distributor 'The X.Org Foundation', version 11.0.12101013 > System Description: Linux From Scratch r12.2-17-systemd > > Configured using: > 'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt6/lib/pkgconfig' > > I haven't tried to debug it and don't really have a good idea how to > proceed with that, but I'll be happy to try any suggestions. However, I > will be traveling for about a week and won't be able to do that till the > end of next week at the earliest. Thanks. If you can investigate the situation where it happens and describe what goes on there, or maybe even suggest what to do about that, it will be very appreciated. Failing that, I hope that you could at least answer the questions I posted about what is special in the situation where it does happen. If you can show a simple recipe that demonstrates the issue without looping endlessly, it will also help.
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 13 Feb 2025 06:23:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 13 01:23:27 2025 Received: from localhost ([127.0.0.1]:39700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tiSdC-0006nw-Vi for submit <at> debbugs.gnu.org; Thu, 13 Feb 2025 01:23:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40530) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tiSd9-0006ng-Ub for 76186 <at> debbugs.gnu.org; Thu, 13 Feb 2025 01:23: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 1tiSd3-0005YA-UR; Thu, 13 Feb 2025 01:23:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=LVOjYFdCl1cpSibOwV/DTvilxGvG3ZJWfjM1F1+7Sfg=; b=CgTxTQVKKvJ+ qXOhJG6N1Q6TfYw7wFXoHx1GwbFgzBc4Q7hZLLsCvV/S+A0vKiYN6obTw/g1BfarbnPgiI3mRqYPC oi77GB+PzlIvvFtlO4vJEGCBsawJBLrzOTDK/AZhBbe16ojQPvcNYNUe8skLF2zJB21P8LOmydLup b77EikC+wgYrwo5vrmTFUL9ryG+SxIS4WU7OHcv78juetkHYNoBv3s/2H5K46F90mhZYLPfChyfSr Og8xWcuVd+2Cx1jeszWY4+STONcrk8rVeFaQM8Q3kUHEZyP6P8jokqsf4x0huJb8YcYq3I0zloLHe liHGAOcPdyBs2CQBO3HL2w==; Date: Thu, 13 Feb 2025 08:23:16 +0200 Message-Id: <86ikpejrcb.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Markus Triska <triska@HIDDEN> In-Reply-To: <87mseqeuox.fsf@HIDDEN> (message from Markus Triska on Wed, 12 Feb 2025 22:09:50 +0100) Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76186 Cc: 76186 <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: Markus Triska <triska@HIDDEN> > Cc: 76186 <at> debbugs.gnu.org > Date: Wed, 12 Feb 2025 22:09:50 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > Or maybe you could just post the real-life scenario where this > > happened to you. Or did that also happen when you invoke recenter in > > a loop? > > Yes of course: The real-life scenario where I noticed this problem is a > situation where I use (recenter 0) in an Elisp application, with the > expectation that it - as documented - recenters point at the topmost > line of the window. The application works well, and recentering > generally works as expected. However, I noticed that sometimes (rarely), > it does not work, even in situations where at other times it works as > expected. What is special or noteworthy about the cases where it doesn't work as expected? Is the frame or the window of some special (e.g., small) dimensions? or is the font used to display characters something special? or are the lines long? or are lines truncated? or is the expected window-start point in some special place, or inside a text property or overlay? anything else that is special about those cases?
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 12 Feb 2025 22:05:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 12 17:05:39 2025 Received: from localhost ([127.0.0.1]:38757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tiKrT-0003gI-AC for submit <at> debbugs.gnu.org; Wed, 12 Feb 2025 17:05:39 -0500 Received: from [78.47.144.35] (port=47532 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <triska@HIDDEN>) id 1tiKrQ-0003g3-Q8 for 76186 <at> debbugs.gnu.org; Wed, 12 Feb 2025 17:05:37 -0500 Received: by metalevel.at (Postfix, from userid 1000) id A682A9C78D; Wed, 12 Feb 2025 23:05:34 +0100 (CET) From: Markus Triska <triska@HIDDEN> To: Stephen Berman <stephen.berman@HIDDEN> Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> <87r042q173.fsf@HIDDEN> Date: Wed, 12 Feb 2025 23:05:34 +0100 In-Reply-To: <87r042q173.fsf@HIDDEN> (Stephen Berman's message of "Wed, 12 Feb 2025 22:53:52 +0100") Message-ID: <87jz9uom35.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Stephen Berman <stephen.berman@HIDDEN> writes: > I can reproduce the issue, both with the original code snippet and the > current one, on this system: Thank you so much Steve! I greatly appreciate you taking the time to try the example, and I am very glad that you can confirm this issue, because this may help us to better reproduce and narrow down t [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in sa-trusted.bondedsender.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in bl.score.senderscore.com] 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 76186 Cc: 76186 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> 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.3 (/) Stephen Berman <stephen.berman@HIDDEN> writes: > I can reproduce the issue, both with the original code snippet and the > current one, on this system: Thank you so much Steve! I greatly appreciate you taking the time to try the example, and I am very glad that you can confirm this issue, because this may help us to better reproduce and narrow down the problem. > However, I will be traveling for about a week and won't be able to do > that till the end of next week at the earliest. Please enjoy your travel! I am grateful for every input, no matter when it arrives. I first encountered the issue more than one year ago, and I look forward to working on it with you when you have time. Please let me know any time if you have any questions or comments. Thank you and all the best, Markus
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 12 Feb 2025 21:54:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 12 16:54:04 2025 Received: from localhost ([127.0.0.1]:38724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tiKgG-0008Rv-3D for submit <at> debbugs.gnu.org; Wed, 12 Feb 2025 16:54:04 -0500 Received: from mout.gmx.net ([212.227.17.22]:59375) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <stephen.berman@HIDDEN>) id 1tiKgB-0008RL-W9 for 76186 <at> debbugs.gnu.org; Wed, 12 Feb 2025 16:54:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1739397233; x=1740002033; i=stephen.berman@HIDDEN; bh=0uyKTX8GQhYCAZrPLxluY0ppLXm6JSBu1MiLBL/hx5E=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=IsoP2ZD1GmlIvZIuCn/Cdd5WvPLpwtEZ0MJd5GHh/d9jGFzB985q9cFYC2TGzQ++ EzDNUgId365ip7T6w85nXrJmkmiUDzsNT11PrU4yyNNvKwTWTVMYrIkIhzqqKhoAW hP4neInMCGl8GMcIMzyz6aEQgL8nCZEM+3/ozMnSKSs/W7UXnAFEcTII9hdgRgiCJ UhSSa5ARWNv5ceY9ElSYV15k4To72UlSEwew4vOMVej0rmj+he6bpADRgKToHAq94 9dTfNpH37IhG7m6xTTfIha8zsT5irHpjemsZPZ7dbDL4orj+gNJbZ0+5MiYPmEcWS m/Eqf0I2DyiABM+a3Q== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from strobelfssd ([94.134.94.69]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MDQeU-1tZ1XT2D4A-0002mN; Wed, 12 Feb 2025 22:53:53 +0100 From: Stephen Berman <stephen.berman@HIDDEN> To: Markus Triska <triska@HIDDEN> Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected In-Reply-To: <87mseqeuox.fsf@HIDDEN> References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> <87mseqeuox.fsf@HIDDEN> Date: Wed, 12 Feb 2025 22:53:52 +0100 Message-ID: <87r042q173.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:vpPtGi+A0NGZjmdvSqK1OQlWIZ8HlOYoEyx5sSRlm/kKGsfSEQJ AMmdE9wcBrzPO6qzA0A+DkScCTOW3PjDpbct2VIvqRHyuKgJeGV3e0NW5qv7TPzatx5Sbje UgMw2GXEScDQQ0geRMc4ODiBsHbKAkMTp2MrOzoUOtvxqEYr9qOI2wLQKunB5GUEH12SFrc 7uPYpyhJQJmRk81JHchpQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:1OOCnFXmGpw=;KiUIPMIZIv0Gv8qARWCUQntGfM7 4dR1dYJqBg+t1SVXkx4hYfLZIFH02LaJqDf0DA/ggT1pDoxp6cPhkyTebOI4kQ4FDXfTPd5rB iKi3lvLoF7MQ4u+JyxzQ7jhMUSY0TOjSxRuueeGa+dxWW1JyFeNPvDxQoDVUUi14sKZD9xw/q Rbg52nOmO5IHm7KBKoDYPm0qfRwJ5Qba8b0nnBE8F8XHtjjwKotzT3UBfgFO4ghL8oJqE5ASq qALTF2StKT8sypywHyWUfuixSI8RRO0x3WwciKKgMT603NHMuoMi2vtZ013mty2L8BbCbU2O9 1AEAu2zOxE1uUlvBj5hHxCewq+15DY8a5f1Q8s/JpHXxnRp6zFwdvOPof/KDK1XaiAqtb4fEt +ApyPTt/RbOfNTucTamJbp5fIEgx1pUbFi0nE/Zrua3QDc/QYdNsMBZ+FHtJYxTGK+pmjJWcY f6m9OOL0YYqaTDxuW/unLVzOjUHYREKOAHXBHgLouBT0pVgvCqlmc5hO6u9hHeS+E3hd3qp6t SxQop79KuMv3l71lZEgBK4Kgj6mI38lrmeXPcCRNGXVzUq6cz+2uSisaaB3IxTiEjLA3damgf bYrS5ApBWfRBs5/sbxaoWtgJtjF0gUTj2j4GkwTlU6j3q8bjdwGFTJDjNyEgDX9dVYabuwEgk xl+xKzLNW7s6MklkCla0/+FdlvxBa1xyip6QEtrKkHi8zO1OjI806MfYfx18HHkh2Th9CVOYX yfj4BKBObayd+3Qh1RyCGJDz7Ss59VFEpyCjydw1NZ3xU2Au3ktxTmnfzUtBSdEwIHZ5ksum3 xXcNRGulUWY20V//JY2xFOAVewsQA9hUBwNEhc9pE+kKYrTsqPf/hzZH3DawkPWWoxjbOTb3q Q8YIS4+kclJLZ4pm1XC4X3TxILYdVUe67T09NfHogcBj9F/7WTF7s4VIElzMXCuPFrFwjHFSz FOZQSMB9P1YRBYwd+Y9yHEpM08r2jlpwTKclbWOlqfiJZstCEaWxPKTOfaMeVa5nTEyMTuLJU 8mW+9jYKN/xcaOm+vwpWJzFb6UCLVqpxTpHLGujMt/4AuxT9upr8eG380yB3UVVz3bz/xha95 F10hjIEh+zacduGh2CeuGrWIDZerfCLqUVmTLS5SNTnqdt441eqzBFh35n+HMLDqkGJjqwUiE pU29bVSENku8wVyO7OB0u4HFabFNwA5Zk2lRtpQPkVMs3y+eE29VS0aGXypKFlM2jlLG32rMh 0QrycdjwkZgNgR1Jr2GcnCdB8dhQfDtosF3iNGlEaFncd/UD4asvp/MrgBUH64XBSLdwPhUPE JRFs+pWkcQQMb1yli7BWqH77D2sJ5Y4BZ5tF5a8NGBd8vR7BVkglTRBst9YJRU2WdM6E0f+yF Non81V9jVwz1hKrUP0+QvncU7GfKFahfquKoHWomojnVEYTosSHPBr4F8p2gtLZ5w84378pnZ rn6zxKw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 76186 Cc: 76186 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> 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 (-) On Wed, 12 Feb 2025 22:09:50 +0100 Markus Triska <triska@HIDDEN> wrote: > Eli Zaretskii <eliz@HIDDEN> writes: > >> They still don't reproduce the problem for me. And I cannot really >> try playing with the various settings that might affect this because >> the recipe runs in a loop, all the time changing the frame being >> tested. >> >> Like I said: it will be much easier if you provide just one >> configuration for the frame in which you see the problem, because then >> I could try changing the font and the dimensions until I succeed in >> triggering. > > The issue the snippet is intended to demonstrate is that recentering > does not work in rare cases, even when used with the exact same settings > as in those cases where it works. This is the reason why a loop is > involved that repeats the exact steps over and over, in order to attempt > to elicit the rare case in which the exact same steps unexpectedly yield > a different result than in all other cases where they are executed. > > If I find a test case where recentering always yields an unexpected > result, I will add it immediately to this issue. > >> Or maybe you could just post the real-life scenario where this >> happened to you. Or did that also happen when you invoke recenter in >> a loop? > > Yes of course: The real-life scenario where I noticed this problem is a > situation where I use (recenter 0) in an Elisp application, with the > expectation that it - as documented - recenters point at the topmost > line of the window. The application works well, and recentering > generally works as expected. However, I noticed that sometimes (rarely), > it does not work, even in situations where at other times it works as > expected. The snippet I posted is an attempt to distill the essence of > the issue, by retaining only those instructions that suffice to exhibit > the issue on both of the two systems I tested it with so far (OSX and > Debian). > >> People who can reproduce this are welcome to debug the problem and >> describe what they saw. > > Yes, thank you a lot, it would already help me greatly to know that > someone can also see the issue with the example I posted. I will also > try to find a way to make it more reproducible, also by testing it on > other systems I have access to. I can reproduce the issue, both with the original code snippet and the current one, on this system: GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2) of 2025-02-06 built on strobelfssd Repository revision: ea04dd8ca93d609c0ee475c4acf58a56dfc0f1f3 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101013 System Description: Linux From Scratch r12.2-17-systemd Configured using: 'configure -C 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt6/lib/pkgconfig' I haven't tried to debug it and don't really have a good idea how to proceed with that, but I'll be happy to try any suggestions. However, I will be traveling for about a week and won't be able to do that till the end of next week at the earliest. Steve Berman
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 12 Feb 2025 21:09:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 12 16:09:55 2025 Received: from localhost ([127.0.0.1]:38657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tiJzW-0006MM-Mu for submit <at> debbugs.gnu.org; Wed, 12 Feb 2025 16:09:55 -0500 Received: from [78.47.144.35] (port=46838 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <triska@HIDDEN>) id 1tiJzT-0006MD-Mt for 76186 <at> debbugs.gnu.org; Wed, 12 Feb 2025 16:09:52 -0500 Received: by metalevel.at (Postfix, from userid 1000) id 689AE9C789; Wed, 12 Feb 2025 22:09:50 +0100 (CET) From: Markus Triska <triska@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> <86o6z7j57d.fsf@HIDDEN> Date: Wed, 12 Feb 2025 22:09:50 +0100 In-Reply-To: <86o6z7j57d.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 12 Feb 2025 22:09:10 +0200") Message-ID: <87mseqeuox.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > They still don't reproduce the problem for me. And I cannot really > try playing with the various settings that might affect this because > the recipe runs in a loop, all the time changing the frame [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in sa-trusted.bondedsender.org] 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [78.47.144.35 listed in bl.score.senderscore.com] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 SPF_NONE SPF: sender does not publish an SPF Record 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 76186 Cc: 76186 <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: 0.3 (/) Eli Zaretskii <eliz@HIDDEN> writes: > They still don't reproduce the problem for me. And I cannot really > try playing with the various settings that might affect this because > the recipe runs in a loop, all the time changing the frame being > tested. > > Like I said: it will be much easier if you provide just one > configuration for the frame in which you see the problem, because then > I could try changing the font and the dimensions until I succeed in > triggering. The issue the snippet is intended to demonstrate is that recentering does not work in rare cases, even when used with the exact same settings as in those cases where it works. This is the reason why a loop is involved that repeats the exact steps over and over, in order to attempt to elicit the rare case in which the exact same steps unexpectedly yield a different result than in all other cases where they are executed. If I find a test case where recentering always yields an unexpected result, I will add it immediately to this issue. > Or maybe you could just post the real-life scenario where this > happened to you. Or did that also happen when you invoke recenter in > a loop? Yes of course: The real-life scenario where I noticed this problem is a situation where I use (recenter 0) in an Elisp application, with the expectation that it - as documented - recenters point at the topmost line of the window. The application works well, and recentering generally works as expected. However, I noticed that sometimes (rarely), it does not work, even in situations where at other times it works as expected. The snippet I posted is an attempt to distill the essence of the issue, by retaining only those instructions that suffice to exhibit the issue on both of the two systems I tested it with so far (OSX and Debian). > People who can reproduce this are welcome to debug the problem and > describe what they saw. Yes, thank you a lot, it would already help me greatly to know that someone can also see the issue with the example I posted. I will also try to find a way to make it more reproducible, also by testing it on other systems I have access to. Thank you and all the best, Markus
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 12 Feb 2025 20:09:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 12 15:09:25 2025 Received: from localhost ([127.0.0.1]:38447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tiJ2z-0000MZ-6l for submit <at> debbugs.gnu.org; Wed, 12 Feb 2025 15:09:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38526) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tiJ2u-0000ME-EF for 76186 <at> debbugs.gnu.org; Wed, 12 Feb 2025 15:09:23 -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 1tiJ2o-0005Xm-Et; Wed, 12 Feb 2025 15:09:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=MFt1Rk99JFhbayOZlFsuaT6AEnC6/NjK09Y2lgiO6t0=; b=l7p/y0mv5/xk 3livF7kJU20NpbLGtZ1afBK79dWYWITRkLIFWfrg4qJJ2qsHrVH8yE2w5d5CajyQ0oCBatY/whQM0 DdHx2k7aSNVTloz40YqHQyC/taAWN2FKJPX84ayAv+O+h0mlbh42Cci5paR/Juxt/AT012hjb+tn8 K0zOKYCzvb/+W3RRlzY4VBJTrsWGH2V5gzZhPIlDJcZJn72sfyDQyFYvFwKP62EQWiT4SxhflJdQg kHS7kKvdndm0OW/wprk3eRCJu/8VczyRfYT9Op5RuMKggc6Ioduv1Ixtc7Cbz80WGoKU8plFTWjC5 cUTlxjDgj7f3H2FKCl6R5A==; Date: Wed, 12 Feb 2025 22:09:10 +0200 Message-Id: <86o6z7j57d.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Markus Triska <triska@HIDDEN> In-Reply-To: <87ikpgi52k.fsf@HIDDEN> (message from Markus Triska on Tue, 11 Feb 2025 21:45:07 +0100) Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN> <87ikpgi52k.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76186 Cc: 76186 <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: Markus Triska <triska@HIDDEN> > Cc: 76186 <at> debbugs.gnu.org > Date: Tue, 11 Feb 2025 21:45:07 +0100 > > I will try to simplify the instructions further. For now, I hope you can > use them as they are to at least also see the issue on your system. They still don't reproduce the problem for me. And I cannot really try playing with the various settings that might affect this because the recipe runs in a loop, all the time changing the frame being tested. Like I said: it will be much easier if you provide just one configuration for the frame in which you see the problem, because then I could try changing the font and the dimensions until I succeed in triggering. Or maybe you could just post the real-life scenario where this happened to you. Or did that also happen when you invoke recenter in a loop? > Indeed I found the problem much easier to reproduce on OSX, where it > consistently happens within a few tries (also with the latest master > commit from today). However, it also happens on other systems, such as: > > In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw > scroll bars) of 2025-02-11 built on debian > Repository revision: 0e76716c5faa5e91ac3913b02ba4dc690cf5df83 > Repository branch: master > Windowing system distributor 'The X.Org Foundation', version 11.0.12004000 > System Description: Debian GNU/Linux 10 (buster) > > Configured using: > 'configure --with-x-toolkit=lucid --with-xpm=ifavailable > --with-gif=ifavailable --with-tiff=ifavailable > --with-gnutls=ifavailable' People who can reproduce this are welcome to debug the problem and describe what they saw.
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at 76186) by debbugs.gnu.org; 11 Feb 2025 20:45:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 15:45:13 2025
Received: from localhost ([127.0.0.1]:59034 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1thx84-0003gp-Lg
for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 15:45:13 -0500
Received: from [78.47.144.35] (port=59474 helo=metalevel.at)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <triska@HIDDEN>) id 1thx80-0003QN-P9
for 76186 <at> debbugs.gnu.org; Tue, 11 Feb 2025 15:45:11 -0500
Received: by metalevel.at (Postfix, from userid 1000)
id 5825F9C79B; Tue, 11 Feb 2025 21:45:07 +0100 (CET)
From: Markus Triska <triska@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#76186: 31.0.50;
(recenter 0) sometimes does not recenter as expected
References: <m2y0ydo2ng.fsf@HIDDEN> <86bjv8y7s5.fsf@HIDDEN>
Date: Tue, 11 Feb 2025 21:45:07 +0100
In-Reply-To: <86bjv8y7s5.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 11 Feb
2025 14:39:54 +0200")
Message-ID: <87ikpgi52k.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > I suspect that this
has something to do with dimensions of frame > decorations in your build
and the size of the default font on your > system (which is different from
mine). Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 SPF_NONE SPF: sender does not publish an SPF Record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.47.144.35 listed in bl.score.senderscore.com]
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[78.47.144.35 listed in sa-trusted.bondedsender.org]
1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Debbugs-Envelope-To: 76186
Cc: 76186 <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: 0.3 (/)
Eli Zaretskii <eliz@HIDDEN> writes:
> I suspect that this has something to do with dimensions of frame
> decorations in your build and the size of the default font on your
> system (which is different from mine).
Yes indeed, this definitely plays an important role. I have now
constructed a case that exhibits the issue within 10 seconds, with an
Emacs commit from today (0e76716c5faa5e91ac3913b02ba4dc690cf5df83).
It shows the issue also on my Debian system if I invoke Emacs with:
$ emacs -Q -fn "Deja Vu Sans Mono 15"
and then paste the forms below in the *scratch* buffer, and then do:
M-x eval-buffer RET
and then wait for about 10 seconds.
The interaction between scroll-bar-mode, frame geometry and other
factors also seems to play a role.
> By contrast, a problem that is hard or impossible to reproduce cannot
> be efficiently investigated.
I will try to simplify the instructions further. For now, I hope you can
use them as they are to at least also see the issue on your system.
> It could also be that the reason is the idiosyncratic implementation
> of the various redisplay aspects on macOS, in which case it is
> possible that this problem could be reproduce on no other system.
Indeed I found the problem much easier to reproduce on OSX, where it
consistently happens within a few tries (also with the latest master
commit from today). However, it also happens on other systems, such as:
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw
scroll bars) of 2025-02-11 built on debian
Repository revision: 0e76716c5faa5e91ac3913b02ba4dc690cf5df83
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)
Configured using:
'configure --with-x-toolkit=lucid --with-xpm=ifavailable
--with-gif=ifavailable --with-tiff=ifavailable
--with-gnutls=ifavailable'
> Last, but not least: Emacs never promises that every setting of
> window-start will be always obeyed. The display engine tries to obey
> it, but if doing so violates some of the restrictions, like having the
> line showing cursor fully visible, it will choose a different
> window-start point. So there's no way to guarantee, in general, that
> setting window-start will be obeyed in 100% of cases, with the current
> Emacs display engine design.
Yes, thank you for pointing this out. Still, the situation I show here
seems consistently to be the same, and recentering sometimes works as
expected and sometimes not, while the buffer contents and positions are
the same between runs.
The updated Lisp forms follow.
Thank you and all the best,
Markus
;; 1) $ emacs -Q -fn "Deja Vu Sans Mono 15"
;; 2) paste the instructions below to the *scratch* buffer
;; 3) M-x eval-buffer RET
;; 4) wait until an exception is thrown
(menu-bar-mode 0)
(tool-bar-mode 0)
(scroll-bar-mode 0)
(set-frame-height nil 27)
(set-frame-width nil 102)
(defvar recentering-test-run 0)
(defun sometimes-not-recentering ()
(interactive)
(setq recentering-test-run (1+ recentering-test-run))
(let ((buf (get-buffer-create "sample")))
(switch-to-buffer buf)
(make-local-variable 'face-remapping-alist)
(setq face-remapping-alist '((default (:family "DejaVu Sans Mono"
:height 218))))
(erase-buffer)
(save-excursion
(dotimes (i 100)
(insert (format "line %d\n" i))))
(let ((frame (make-frame `((parent-frame . ,(selected-frame))
(left . 200)
(top . 200)
(width . (text-pixels . 100))
(height . (text-pixels . 100)))))
(buf (get-buffer-create "buffer-in-frame")))
(with-selected-frame frame
(switch-to-buffer buf)
(erase-buffer)
(insert "Hello!"))
(redisplay)
(delete-frame frame)
(kill-buffer buf)
(goto-char (point-max))
(insert "\n\n")
(recenter 0)
(redisplay)
(unless (= (window-start) (point-max))
(message "window-start unexpectedly not at point-max (%d != %d) in run %d"
(window-start) (point-max) recentering-test-run)
(setq recentering-test-run 0)
(error 'not-recentered t)))))
(while t
(sometimes-not-recentering))
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.Received: (at 76186) by debbugs.gnu.org; 11 Feb 2025 12:40:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 07:40:32 2025 Received: from localhost ([127.0.0.1]:54821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1thpZ2-000803-2x for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 07:40:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45296) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1thpYy-0007zk-V6 for 76186 <at> debbugs.gnu.org; Tue, 11 Feb 2025 07:40:29 -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 1thpYn-0002Er-Qi; Tue, 11 Feb 2025 07:40:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=UAE6w5jPx5ArxNG9CzAhQeoEfZ5HkLBGRIL1DLw7TVw=; b=q6Kredv2RO80 59ieimjNOOUO3dDS9VNeXreoTvJGYyfZ97fPVyx4GPB/dbjM/XrpeUWmMId6rnVE+knatiiksmqL/ j+ippSuK9YC7fJkGrnKOthLUnwKb7t5CwWAjq+65YNxgG+6DuPBxPqQ4Jz+13iz4lNJ/mTbGlk8IH VwE2rD91IxqaOOrJk6cWgO3FWTZaHcqntDqkjIOl4LwbMJOARrOA4UFEFmaTsRKf5SOmgDBvp6Rlc da3ilxrvpBRynzwzaiN70aZ/HMouuPSEiQ7yowWYJdocQ0mKnBzONe+V1X8LqDZ5UPo3kazuD8X3b BqaahJF49DzuPyX1hC545w==; Date: Tue, 11 Feb 2025 14:39:54 +0200 Message-Id: <86bjv8y7s5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Markus Triska <triska@HIDDEN> In-Reply-To: <m2y0ydo2ng.fsf@HIDDEN> (message from Markus Triska on Mon, 10 Feb 2025 23:28:35 +0100) Subject: Re: bug#76186: 31.0.50; (recenter 0) sometimes does not recenter as expected References: <m2y0ydo2ng.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76186 Cc: 76186 <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: Markus Triska <triska@HIDDEN> > Date: Mon, 10 Feb 2025 23:28:35 +0100 > > > To reproduce this issue, please start Emacs with: > > $ emacs -Q > > Then paste the forms below in the *scratch* buffer and evaluate them > with M-x eval-buffer RET. > > The function `sometimes-not-recentering' (defined below) illustrates the > issue I want to show: Sometimes (recenter 0) works as expected, and > makes (window-start) the same as (point-max). But in some cases, the > recentering does not work as expected. In such a case, the function > throws an exception. > > You can invoke the function as often as you want, using for example: > > M-x sometimes-not-recentering RET > > and then invoke the function over and over with: > > C-x z z z z z z z z .... > > until, at one point, we see in the minibuffer: > > apply: Wrong type argument: stringp, not-recentered > > in that case, do C-h e to see additional information in the *Messages* > buffer. For example, after the most recent tries I performed, I got: > > window-start unexpectedly not at point-max (671 != 793) in run 3 I cannot reproduce this, at least not after a reasonably long sequence of z's. I suspect that this has something to do with dimensions of frame decorations in your build and the size of the default font on your system (which is different from mine). In any case, it is much better to show a recipe that doesn't require one to endlessly repeat some command until the problem happens (or doesn't). In this case, if you can capture the precise dimensions and position of the frame that cause the problem, just show a simple one-time recipe with those values. Then, even if on other platforms we need to modify the numbers in small ways, it can be done relatively easily, and the issue then investigated without difficulties. By contrast, a problem that is hard or impossible to reproduce cannot be efficiently investigated. It could also be that the reason is the idiosyncratic implementation of the various redisplay aspects on macOS, in which case it is possible that this problem could be reproduce on no other system. Last, but not least: Emacs never promises that every setting of window-start will be always obeyed. The display engine tries to obey it, but if doing so violates some of the restrictions, like having the line showing cursor fully visible, it will choose a different window-start point. So there's no way to guarantee, in general, that setting window-start will be obeyed in 100% of cases, with the current Emacs display engine design. > In GNU Emacs 31.0.50 (build 1, x86_64-apple-darwin18.2.0, X toolkit, > cairo version 1.17.6, Xaw scroll bars) of 2025-01-22 built on > mac-mini > Repository revision: 34166dcf9cbd961d4f53ce9029e179a21a12c001 > Repository branch: master This is a relatively old build. Since there were many changes lately in the display parts, due to new features and fixing regressions, I suggest to update from Git before you do anything else (unless the dsame problem exists also on the emacs-30 release branch).
bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 10 Feb 2025 21:56:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 10 16:56:40 2025
Received: from localhost ([127.0.0.1]:52808 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1thblg-0005iU-DB
for submit <at> debbugs.gnu.org; Mon, 10 Feb 2025 16:56:40 -0500
Received: from lists.gnu.org ([2001:470:142::17]:52972)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <triska@HIDDEN>)
id 1thbla-0005hs-5u
for submit <at> debbugs.gnu.org; Mon, 10 Feb 2025 16:56:37 -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 <triska@HIDDEN>)
id 1thblT-0003RB-O5
for bug-gnu-emacs@HIDDEN; Mon, 10 Feb 2025 16:56:27 -0500
Received: from [78.47.144.35] (helo=metalevel.at)
by eggs.gnu.org with esmtp (Exim 4.90_1)
(envelope-from <triska@HIDDEN>) id 1thblQ-0006f6-Ni
for bug-gnu-emacs@HIDDEN; Mon, 10 Feb 2025 16:56:27 -0500
Received: from mts-Mac-mini.localdomain (localhost [127.0.0.1])
by metalevel.at (Postfix) with ESMTP id 231209C77B
for <bug-gnu-emacs@HIDDEN>; Mon, 10 Feb 2025 22:47:08 +0100 (CET)
Received: by mts-Mac-mini.localdomain (Postfix, from userid 501)
id 71DEF3443A70; Mon, 10 Feb 2025 23:28:35 +0100 (CET)
From: Markus Triska <triska@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; (recenter 0) sometimes does not recenter as expected
X-Debbugs-Cc:
Date: Mon, 10 Feb 2025 23:28:35 +0100
Message-ID: <m2y0ydo2ng.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Host-Lookup-Failed: Reverse DNS lookup failed for 78.47.144.35 (failed)
Received-SPF: none client-ip=78.47.144.35; envelope-from=triska@HIDDEN;
helo=metalevel.at
X-Spam_score_int: -10
X-Spam_score: -1.1
X-Spam_bar: -
X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
RDNS_NONE=0.793, SPF_HELO_NONE=0.001,
SPF_NONE=0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.0 (/)
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: -1.0 (-)
To reproduce this issue, please start Emacs with:
$ emacs -Q
Then paste the forms below in the *scratch* buffer and evaluate them
with M-x eval-buffer RET.
The function `sometimes-not-recentering' (defined below) illustrates the
issue I want to show: Sometimes (recenter 0) works as expected, and
makes (window-start) the same as (point-max). But in some cases, the
recentering does not work as expected. In such a case, the function
throws an exception.
You can invoke the function as often as you want, using for example:
M-x sometimes-not-recentering RET
and then invoke the function over and over with:
C-x z z z z z z z z ....
until, at one point, we see in the minibuffer:
apply: Wrong type argument: stringp, not-recentered
in that case, do C-h e to see additional information in the *Messages*
buffer. For example, after the most recent tries I performed, I got:
window-start unexpectedly not at point-max (671 != 793) in run 3
This means that the recentering worked twice as expected, and then did
not work as expected in the third run. In some runs I performed with
earlier Emacs versions, recentering worked as expected 200 times and
more in a row, and then did not work as expected after that. After C-x z
z z ..., simply keep "z" pressed until the exception occurs.
The forms follow below. I would greatly appreciate your help with this.
Please let me know any time if you have any questions about this issue.
Thank you and all the best,
Markus
(defvar recentering-test-run 0)
(defun sometimes-not-recentering ()
(interactive)
(setq recentering-test-run (1+ recentering-test-run))
(let ((buf (get-buffer-create "sample")))
(switch-to-buffer buf)
(erase-buffer)
(save-excursion
(dotimes (i 100)
(insert (format "line %d\n" i))))
(let ((frame (make-frame `((parent-frame . ,(selected-frame))
(left . 200)
(top . 200)
(width . (text-pixels . 100))
(height . (text-pixels . 100)))))
(buf (get-buffer-create "buffer-in-frame")))
(with-selected-frame frame
(switch-to-buffer buf)
(erase-buffer)
(insert "Hello!"))
(redisplay)
(delete-frame frame)
(goto-char (point-max))
(insert "\n\n")
(recenter 0)
(redisplay)
(unless (= (window-start) (point-max))
(message "window-start unexpectedly not at point-max (%d != %d) in run %d"
(window-start) (point-max) recentering-test-run)
(setq recentering-test-run 0)
(error 'not-recentered t)))))
In GNU Emacs 31.0.50 (build 1, x86_64-apple-darwin18.2.0, X toolkit,
cairo version 1.17.6, Xaw scroll bars) of 2025-01-22 built on
mac-mini
Repository revision: 34166dcf9cbd961d4f53ce9029e179a21a12c001
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Mac OS X 10.14.2
Configured using:
'configure --with-x-toolkit=lucid --without-ns
CFLAGS=-I/opt/local/include/ LDFLAGS=-L/opt/local/lib
--with-xpm=ifavailable'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBXML2 MODULES NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS
TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 LUCID
ZLIB
Markus Triska <triska@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#76186; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.