Received: (at 53798-done) by debbugs.gnu.org; 19 Feb 2025 12:19:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 19 07:19:48 2025 Received: from localhost ([127.0.0.1]:44265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkj3M-0000U8-D3 for submit <at> debbugs.gnu.org; Wed, 19 Feb 2025 07:19:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38138) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tkj3K-0000TU-1a for 53798-done <at> debbugs.gnu.org; Wed, 19 Feb 2025 07:19:46 -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 1tkj3D-0007In-SV; Wed, 19 Feb 2025 07:19:39 -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=adQhQqwFKZ6opeyY08kvelRaZ9Rk8tBj+Y//xZEvr1g=; b=IU09c+10S9dP HGpX9AEJ1Xz5TfiG+iIauwqk+HkZtd1UFyYR/RzcpwyXN3zQXGcBOHnw9G9vEYwuTEngmd2w2BgTd kZ8ii2k3BQTAlvDc61HvoNnSgxRD07f3mQaJiS2SCoo38PwPBcmDC6gE7wLHj+heaV2eAvxg6Nt4C kqvTJYWxhMMUEAADiHMJntiL+AWSTzcK00c3UEVYNAPgA46ROvP43KXAMcKG+7cy3K5qvD/uRE0rX EM1ItIlzxKsxgAdGuTRagloJAVkY4YxHBjDYs4Qle1jAndrJZ/ZG5aLEP+8nG959yt/fkpw5yAbQW FywM+z1dHpGt5r7vS1EbQw==; Date: Wed, 19 Feb 2025 14:19:37 +0200 Message-Id: <865xl66s9y.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Markus Triska <triska@HIDDEN> In-Reply-To: <87zfijx786.fsf@HIDDEN> (message from Markus Triska on Tue, 18 Feb 2025 22:39:53 +0100) Subject: Re: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay References: <m2y22pfprh.fsf@HIDDEN> <83leyp1mte.fsf@HIDDEN> <87tuddxlwb.fsf@HIDDEN> <83ee4h196x.fsf@HIDDEN> <87h79duq77.fsf@HIDDEN> <83a6f517mw.fsf@HIDDEN> <87zfijx786.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53798-done Cc: 53798-done <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: 53798 <at> debbugs.gnu.org > Date: Tue, 18 Feb 2025 22:39:53 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > notice that the redisplay architecture on macOS have changed > > dramatically since Emacs 27.1, so maybe the current code base no > > longer behaves like what you see. > > I can no longer reproduce the issue on OSX 10.14.2, where the examples I > posted in this thread all work as intended. Therefore, please consider > closing the issue. Thanks, closing.
Markus Triska <triska@HIDDEN>:Eli Zaretskii <eliz@HIDDEN>:Received: (at 53798) by debbugs.gnu.org; 18 Feb 2025 21:40:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 16:40:00 2025 Received: from localhost ([127.0.0.1]:34899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkVJw-0003L4-Ix for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 16:40:00 -0500 Received: from [78.47.144.35] (port=41050 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <triska@HIDDEN>) id 1tkVJq-0003KP-VM for 53798 <at> debbugs.gnu.org; Tue, 18 Feb 2025 16:39:58 -0500 Received: by metalevel.at (Postfix, from userid 1000) id 790899C797; Tue, 18 Feb 2025 22:39:53 +0100 (CET) From: Markus Triska <triska@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay References: <m2y22pfprh.fsf@HIDDEN> <83leyp1mte.fsf@HIDDEN> <87tuddxlwb.fsf@HIDDEN> <83ee4h196x.fsf@HIDDEN> <87h79duq77.fsf@HIDDEN> <83a6f517mw.fsf@HIDDEN> Date: Tue, 18 Feb 2025 22:39:53 +0100 In-Reply-To: <83a6f517mw.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 05 Feb 2022 20:38:15 +0200") Message-ID: <87zfijx786.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: > notice that the redisplay architecture on macOS have changed > dramatically since Emacs 27.1, so maybe the current code base no > longer behaves like what you see. 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-accredit.habeas.com] 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Debbugs-Envelope-To: 53798 Cc: 53798 <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: > notice that the redisplay architecture on macOS have changed > dramatically since Emacs 27.1, so maybe the current code base no > longer behaves like what you see. I can no longer reproduce the issue on OSX 10.14.2, where the examples I posted in this thread all work as intended. Therefore, please consider closing the issue. Thank you and all the best, Markus
bug-gnu-emacs@HIDDEN:bug#53798; Package emacs.
Full text available.
Received: (at 53798) by debbugs.gnu.org; 5 Feb 2022 18:55:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 05 13:55:34 2022
Received: from localhost ([127.0.0.1]:35592 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nGQDe-0004Tg-Gy
for submit <at> debbugs.gnu.org; Sat, 05 Feb 2022 13:55:34 -0500
Received: from [78.47.144.35] (port=46242 helo=metalevel.at)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <triska@HIDDEN>) id 1nGQDc-0004TX-Gv
for 53798 <at> debbugs.gnu.org; Sat, 05 Feb 2022 13:55:32 -0500
Received: by metalevel.at (Postfix, from userid 1000)
id 175179C755; Sat, 5 Feb 2022 19:55:31 +0100 (CET)
From: Markus Triska <triska@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay
References: <m2y22pfprh.fsf@HIDDEN> <83leyp1mte.fsf@HIDDEN>
<87tuddxlwb.fsf@HIDDEN> <83ee4h196x.fsf@HIDDEN>
<87h79duq77.fsf@HIDDEN> <83a6f517mw.fsf@HIDDEN>
Date: Sat, 05 Feb 2022 19:55:31 +0100
In-Reply-To: <83a6f517mw.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 05 Feb
2022 20:38:15 +0200")
Message-ID: <875yptb0t8.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: > If you want Emacs to
do something, why do you care about redisplay and > its rate? Redisplay cannot
affect what Emacs does, it just reflects > the snapshot of the state.
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
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
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 53798
Cc: 53798 <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:
> If you want Emacs to do something, why do you care about redisplay and
> its rate? Redisplay cannot affect what Emacs does, it just reflects
> the snapshot of the state.
In many such cases, I would like to get an expression about how far
along Emacs has already come, and also to see whether the actions I
automated contain obvious errors which would become immediately apparent
from seeing a sequence of intermediary steps which are displayed like a
movie. In addition, also in cases where I do know that everything works
correctly, I would often like to show these steps to others so that they
get an impression about what is going on internally. Seeing only a
stalled Emacs prevents a truly impressive and enjoyable presentation. In
addition, I would like to automate everything reliably in the sense that
it runs in the same way irrespective of what else is going on, such as
whether a key is accidentally pressed, the mouse is moved etc.
> I don't understand why you care. Why not leave Emacs to its devices,
> so it performs redisplay when it finishes whatever it is that you want
> it to do?
In this concrete case, I looked at the documentation of `redisplay', and
it reads, at the start:
Perform redisplay.
Since I see no redisplay, I wondered whether the documentation is in
fact correct. This is what led me to reporting this issue, in the hope
that someone cares sufficiently about Emacs to align the functionality
of redisplay with its documentation.
> I think Alan or someone else who can look into this stuff on macOS
> should chime in, because it sounds like its macOS specific. I also
> notice that the redisplay architecture on macOS have changed
> dramatically since Emacs 27.1, so maybe the current code base no
> longer behaves like what you see.
Thank you a lot! If there are any questions, please let me know.
All the best,
Markus
bug-gnu-emacs@HIDDEN:bug#53798; Package emacs.
Full text available.Received: (at 53798) by debbugs.gnu.org; 5 Feb 2022 18:39:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 05 13:39:18 2022 Received: from localhost ([127.0.0.1]:35579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nGPxu-000446-H9 for submit <at> debbugs.gnu.org; Sat, 05 Feb 2022 13:39:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1nGPxs-00043t-T6 for 53798 <at> debbugs.gnu.org; Sat, 05 Feb 2022 13:39:17 -0500 Received: from [2001:470:142:3::e] (port=39634 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1nGPxP-0006HJ-8Y; Sat, 05 Feb 2022 13:39:11 -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=/g+aJZImzKSuV47urM3W+anSkOh8N/1urljD5krMxr4=; b=RoDSapMl8wV2 oIPfhUI9vodgTnlZOfdX7EQ+lRA/qVczrlxZCEUXVEGQ4LkLhTOKVdIEutFPTfpff33AbCPnsvldp h1yK78LtHjJIzyGp1l89Boak/H8WZRq6nC1D/J3JHOsskW+FGqqGMP5egMTt+34EEEqJ4RrkQcwNS Qg5vnQm8YwKnaS5JDE9fDScF3AInXM4tPWMeZ/kj1+ztWOyxbK3lJX5F20IIIFO0EeWlFQTP2sult 3NL5/CuF1JJkaYCjCQ5373CdPpn3FnJdN2DwsBlfhgLcIwia6xpz73E17uLCWR779384ofok+4t7a fCWZ60J24J6dfjZJe9lWPA==; Received: from [87.69.77.57] (port=1136 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1nGPxJ-0001fI-DS; Sat, 05 Feb 2022 13:38:47 -0500 Date: Sat, 05 Feb 2022 20:38:15 +0200 Message-Id: <83a6f517mw.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Markus Triska <triska@HIDDEN> In-Reply-To: <87h79duq77.fsf@HIDDEN> (message from Markus Triska on Sat, 05 Feb 2022 19:24:28 +0100) Subject: Re: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay References: <m2y22pfprh.fsf@HIDDEN> <83leyp1mte.fsf@HIDDEN> <87tuddxlwb.fsf@HIDDEN> <83ee4h196x.fsf@HIDDEN> <87h79duq77.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53798 Cc: 53798 <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: 53798 <at> debbugs.gnu.org > Date: Sat, 05 Feb 2022 19:24:28 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > If you press several keys, you need to call read-char that number of > > time, or empty the input queue in some other way. Otherwise, you > > still have input available after calling read-char, like in the > > original recipe, because you pressed more than one key. > > I tried to do this by using as the final form instead: > > (while t > (transform-line) > (redisplay) > (while (input-pending-p) > (read-char)) > (sit-for 0.1)) > > > This reads characters as long as input-pending-p succeeds, in order to > read all characters that are pending. However, I still can reproduce the > issue. Well, I can't. So maybe it's macOS specific. > > I'm not on macOS, so I commented out the part of the recipe that deals > > with interprogram-cut-function. When I run the result, I see no > > abnormal behavior, even if I press several keys. > > I can reproduce this: When I remove these settings, everything works as > intended. This confirms that these settings are relevant to reproduce > this issue. then maybe it really _is_ macOS specific, and I shouldn't speak up here anymore. > The issue I am facing is the following: I have programmed Emacs to > automate several tasks for me. For instance, in the example I posted, > the task is to convert UnicodeData.txt to a collection of Prolog facts > that can be queried and reasoned about with Scryer Prolog. This is an > example of an actual task I am trying to solve. I noticed that when I > start the automation, and then accidentally press a key, the program > seems to stall instead of proceeding as intended, *even* when I take > provisions, within the program, that aim to counteract the stall. For > example, in the sample snippet I posted, I tried to manually enforce a > redisplay by calling (redisplay), and still I do not see a > redisplay. Instead, I see no display update at all for many iterations. If you want Emacs to do something, why do you care about redisplay and its rate? Redisplay cannot affect what Emacs does, it just reflects the snapshot of the state. > > What do you mean by "how Emacs redisplays things"? In these recipes, > > you actually force Emacs to do redisplay, both by calling 'redisplay' > > and by calling 'sit-for', instead of letting it do it "naturally". So > > I wonder where all this is going, and why. > > I am *trying* to force Emacs to redisplay. The issue I am facing is that > the redisplay does *not* happen, even though I am using (redisplay). I don't understand why you care. Why not leave Emacs to its devices, so it performs redisplay when it finishes whatever it is that you want it to do? > Does this explanation help? Please let me know if there is anything I > can do to help reproduce this. I think Alan or someone else who can look into this stuff on macOS should chime in, because it sounds like its macOS specific. I also notice that the redisplay architecture on macOS have changed dramatically since Emacs 27.1, so maybe the current code base no longer behaves like what you see.
bug-gnu-emacs@HIDDEN:bug#53798; Package emacs.
Full text available.
Received: (at 53798) by debbugs.gnu.org; 5 Feb 2022 18:24:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 05 13:24:32 2022
Received: from localhost ([127.0.0.1]:35564 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nGPjb-0003hN-MD
for submit <at> debbugs.gnu.org; Sat, 05 Feb 2022 13:24:31 -0500
Received: from [78.47.144.35] (port=45950 helo=metalevel.at)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <triska@HIDDEN>) id 1nGPjZ-0003hE-BK
for 53798 <at> debbugs.gnu.org; Sat, 05 Feb 2022 13:24:29 -0500
Received: by metalevel.at (Postfix, from userid 1000)
id 1B6529C753; Sat, 5 Feb 2022 19:24:28 +0100 (CET)
From: Markus Triska <triska@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay
References: <m2y22pfprh.fsf@HIDDEN> <83leyp1mte.fsf@HIDDEN>
<87tuddxlwb.fsf@HIDDEN> <83ee4h196x.fsf@HIDDEN>
Date: Sat, 05 Feb 2022 19:24:28 +0100
In-Reply-To: <83ee4h196x.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 05 Feb
2022 20:04:38 +0200")
Message-ID: <87h79duq77.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: > If you press several
keys, you need to call read-char that number of > time, or empty the input
queue in some other way. Otherwise, you > still have input available after
calling read-char, like in [...]
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
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
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 53798
Cc: 53798 <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:
> If you press several keys, you need to call read-char that number of
> time, or empty the input queue in some other way. Otherwise, you
> still have input available after calling read-char, like in the
> original recipe, because you pressed more than one key.
I tried to do this by using as the final form instead:
(while t
(transform-line)
(redisplay)
(while (input-pending-p)
(read-char))
(sit-for 0.1))
This reads characters as long as input-pending-p succeeds, in order to
read all characters that are pending. However, I still can reproduce the
issue.
>
> I'm not on macOS, so I commented out the part of the recipe that deals
> with interprogram-cut-function. When I run the result, I see no
> abnormal behavior, even if I press several keys.
I can reproduce this: When I remove these settings, everything works as
intended. This confirms that these settings are relevant to reproduce
this issue.
> I'm not sure I understand what you are trying to establish with these
> recipes. What is the actual issue you are trying to solve, and why
> the call to redisplay/sit-for and pressing keys are part of that?
The issue I am facing is the following: I have programmed Emacs to
automate several tasks for me. For instance, in the example I posted,
the task is to convert UnicodeData.txt to a collection of Prolog facts
that can be queried and reasoned about with Scryer Prolog. This is an
example of an actual task I am trying to solve. I noticed that when I
start the automation, and then accidentally press a key, the program
seems to stall instead of proceeding as intended, *even* when I take
provisions, within the program, that aim to counteract the stall. For
example, in the sample snippet I posted, I tried to manually enforce a
redisplay by calling (redisplay), and still I do not see a
redisplay. Instead, I see no display update at all for many iterations.
> What do you mean by "how Emacs redisplays things"? In these recipes,
> you actually force Emacs to do redisplay, both by calling 'redisplay'
> and by calling 'sit-for', instead of letting it do it "naturally". So
> I wonder where all this is going, and why.
I am *trying* to force Emacs to redisplay. The issue I am facing is that
the redisplay does *not* happen, even though I am using (redisplay). In
other words, Emacs seems to be active in the sense that it does perform
the operations I ask of it, but it does not show the result even though
I ask them to be shown.
Does this explanation help? Please let me know if there is anything I
can do to help reproduce this.
Thank you a lot!
Markus
bug-gnu-emacs@HIDDEN:bug#53798; Package emacs.
Full text available.Received: (at 53798) by debbugs.gnu.org; 5 Feb 2022 18:05:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 05 13:05:49 2022 Received: from localhost ([127.0.0.1]:35537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nGPRV-0003Eo-HI for submit <at> debbugs.gnu.org; Sat, 05 Feb 2022 13:05:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1nGPRU-0003EZ-Hw for 53798 <at> debbugs.gnu.org; Sat, 05 Feb 2022 13:05:49 -0500 Received: from [2001:470:142:3::e] (port=38752 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1nGPRO-0001v4-Uu; Sat, 05 Feb 2022 13:05:42 -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=jCNpK1Usmp/fV1gv4x2SVElgN5zQDYadavx80Lpqsnc=; b=TXrOgMeXoPVJ 3BfZBCOnwqunscFvMwU5nrnj4SzLcyf5VBUIn74/VnsVKEdfmidD1RU0JufWe70aXRgO369vw6TEC jT5sqyRNg+FN8vtNc6ch5QCoSIzErMNoHPmvXQNwlnSEMU7p3IlDVYp/WdrDDxgURU43VeiZo3mLX 31ihICxOykQjc6ZDoCGAWQ49tzlNissTYe89uaIhllSVvZg9+jmBLDIQffCsfTWA4u3NHKFuXARpK Rj6fSZxQWgfBNSQEaXPR+abzbxTpdmePchTY3eM+XAm5TGDeBQBG6XIaR/kwQYLjM+OenEySYKlSP KzVEGHRJWNmvd1GZLvJaEg==; Received: from [87.69.77.57] (port=3053 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1nGPQt-00089U-3E; Sat, 05 Feb 2022 13:05:29 -0500 Date: Sat, 05 Feb 2022 20:04:38 +0200 Message-Id: <83ee4h196x.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Markus Triska <triska@HIDDEN> In-Reply-To: <87tuddxlwb.fsf@HIDDEN> (message from Markus Triska on Sat, 05 Feb 2022 18:29:08 +0100) Subject: Re: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay References: <m2y22pfprh.fsf@HIDDEN> <83leyp1mte.fsf@HIDDEN> <87tuddxlwb.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53798 Cc: 53798 <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: 53798 <at> debbugs.gnu.org > Date: Sat, 05 Feb 2022 18:29:08 +0100 > > $ emacs -Q redisplay.el -f eval-buffer > > then the forms will open UnicodeData.txt which ships with Emacs (please > adjust the path if necessary), and then will apply a certain > transformation on each line of the file. > > You will see that each line is changed as intended, and we see each > change immediately as it takes effect. However, unexpectedly, when > several keys are pressed quickly in a row, the program apparently > stalls, and no longer performs any actions, for several seconds. If you press several keys, you need to call read-char that number of time, or empty the input queue in some other way. Otherwise, you still have input available after calling read-char, like in the original recipe, because you pressed more than one key. I'm not on macOS, so I commented out the part of the recipe that deals with interprogram-cut-function. When I run the result, I see no abnormal behavior, even if I press several keys. I'm not sure I understand what you are trying to establish with these recipes. What is the actual issue you are trying to solve, and why the call to redisplay/sit-for and pressing keys are part of that? > I found that the settings of interprogram-cut-function and > save-interprogram-paste-before-kill are relevant to reproduce this > issue. Could it be that how these settings are treated internally may > interfere with how Emacs redisplays things, and whether it stalls? What do you mean by "how Emacs redisplays things"? In these recipes, you actually force Emacs to do redisplay, both by calling 'redisplay' and by calling 'sit-for', instead of letting it do it "naturally". So I wonder where all this is going, and why.
bug-gnu-emacs@HIDDEN:bug#53798; Package emacs.
Full text available.
Received: (at 53798) by debbugs.gnu.org; 5 Feb 2022 17:29:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 05 12:29:11 2022
Received: from localhost ([127.0.0.1]:35504 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nGOs3-0002JT-DA
for submit <at> debbugs.gnu.org; Sat, 05 Feb 2022 12:29:11 -0500
Received: from [78.47.144.35] (port=44960 helo=metalevel.at)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <triska@HIDDEN>) id 1nGOs1-0002JL-Li
for 53798 <at> debbugs.gnu.org; Sat, 05 Feb 2022 12:29:10 -0500
Received: by metalevel.at (Postfix, from userid 1000)
id 2F3F59C754; Sat, 5 Feb 2022 18:29:08 +0100 (CET)
From: Markus Triska <triska@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay
References: <m2y22pfprh.fsf@HIDDEN> <83leyp1mte.fsf@HIDDEN>
Date: Sat, 05 Feb 2022 18:29:08 +0100
In-Reply-To: <83leyp1mte.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 05 Feb
2022 15:10:21 +0200")
Message-ID: <87tuddxlwb.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: > > If I modify the
snippet
as below, it behaves the same no matter > whether you press a key or not.
> Thank you a lot for looking into this issue! You are right: For the snippet
I originally posted, I can fix the issue as you outline.
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
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
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 53798
Cc: 53798 <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:
>
> If I modify the snippet as below, it behaves the same no matter
> whether you press a key or not.
>
Thank you a lot for looking into this issue! You are right: For the
snippet I originally posted, I can fix the issue as you outline.
Since the issue I faced in my original program cannot be solved in this
way, I have now constructed a snippet that shows the problem in a way
that apparently cannot be solved in this way, using the forms that
follow this message.
On OSX, if you save these forms in redisplay.el and then invoke Emacs
with:
$ emacs -Q redisplay.el -f eval-buffer
then the forms will open UnicodeData.txt which ships with Emacs (please
adjust the path if necessary), and then will apply a certain
transformation on each line of the file.
You will see that each line is changed as intended, and we see each
change immediately as it takes effect. However, unexpectedly, when
several keys are pressed quickly in a row, the program apparently
stalls, and no longer performs any actions, for several seconds.
I found that the settings of interprogram-cut-function and
save-interprogram-paste-before-kill are relevant to reproduce this
issue. Could it be that how these settings are treated internally may
interfere with how Emacs redisplays things, and whether it stalls?
To forms to reproduce the issue follow below.
Thank you a lot!
Markus
;; please adapt this as necessary to find UnicodeData.txt
(find-file "~/emacs/admin/unidata/UnicodeData.txt")
(defun transform-line ()
(insert "code_description(")
(forward-word)
(delete-char 1)
(insert ", \"")
(search-forward ";")
(delete-char -1)
(insert "\").")
(kill-line)
(forward-line))
(defun paste-to-osx (text &optional push)
(let ((process-connection-type nil))
(let ((proc (start-process "pbcopy" "*Messages*" "pbcopy")))
(process-send-string proc text)
(process-send-eof proc))))
(setq interprogram-cut-function 'paste-to-osx)
(setq save-interprogram-paste-before-kill t)
(while t
(transform-line)
(redisplay)
(or (sit-for 0.1)
(read-char)))
bug-gnu-emacs@HIDDEN:bug#53798; Package emacs.
Full text available.
Received: (at 53798) by debbugs.gnu.org; 5 Feb 2022 13:10:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 05 08:10:48 2022
Received: from localhost ([127.0.0.1]:34062 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nGKq0-000460-KU
for submit <at> debbugs.gnu.org; Sat, 05 Feb 2022 08:10:48 -0500
Received: from eggs.gnu.org ([209.51.188.92]:60960)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1nGKpz-00045o-2M
for 53798 <at> debbugs.gnu.org; Sat, 05 Feb 2022 08:10:48 -0500
Received: from [2001:470:142:3::e] (port=34152 helo=fencepost.gnu.org)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1nGKpt-0001zj-39; Sat, 05 Feb 2022 08:10: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=wgRPaIgAUlWX8KXwWsa5c8ITJ8JDmpL79Mw16a+aVqM=; b=MdbNMM7t31LA
QUqvBYQu8ERW/Z6SNKw891xTxRaMjdrqm430107yeQGtjSIS7X+hgUR4I+xMnIP6ZijIKBrgmu+dY
rWPTJy3QY6y1n5KCWgolc+/BnSbkhZ83AjxHkUyTZfDjmU6LuQXKEF6UHPLCUewuZHvYIzJuqTrhT
XEbPZz5dFwqYREu2hcg3tFb3eq8KiStwbrF9QZxZSBhiloPLEk9kyfbQdis0205ODagLZeFvwT2Wp
qUCbqp+TE9GP/FgF7Mb+8HIW83ZPKiRH8PgwmXkTe5hFaWfFOC7mbqkA8CNmGmcsrYmBUlTzyd/vb
eSyCzZz+k2Lt5qd1qBzV6w==;
Received: from [87.69.77.57] (port=4645 helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1nGKps-0007Cn-Gl; Sat, 05 Feb 2022 08:10:40 -0500
Date: Sat, 05 Feb 2022 15:10:21 +0200
Message-Id: <83leyp1mte.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Markus Triska <triska@HIDDEN>
In-Reply-To: <m2y22pfprh.fsf@HIDDEN> (message from Markus Triska on Sat,
05 Feb 2022 13:42:58 +0100)
Subject: Re: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay
References: <m2y22pfprh.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 53798
Cc: 53798 <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: Sat, 05 Feb 2022 13:42:58 +0100
>
>
> To reproduce this issue, please start Emacs with:
>
> $ emacs -Q
>
> and evaluate the following form:
>
> (while t
> (insert "\n" (make-string 50 ?a))
> (redisplay)
> (sit-for 0.1))
>
> At first, this works completely as intended: We see a growing number of
> lines in the buffer, and we are shown each fresh line as it appears:
>
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> ...
>
> However, as soon as any key is pressed, the output becomes erratic in
> the sense that for long stretches of time, we see no new lines at all,
> and then several of them appear immediately at the same time.
>
> The snippet uses (redisplay) after writing each line in order to show
> the line as it appears. I therefore expect to continue to see, also when
> a key is pressed, each line immediately after it is written in the
> buffer, not batches of multiple lines to be shown after several of them
> have already been written. Is there any way to obtain this behaviour?
sit-for exits immediately if some input is available, and pressing a
key makes input available. So the loop starts iterating much faster
than before, because sit-for no longer waits for 0.1 sec. And that is
what you see.
If I modify the snippet as below, it behaves the same no matter
whether you press a key or not.
(while t
(insert "\n" (make-string 50 ?a))
(redisplay)
(or (sit-for 0.1)
(read-char)))
bug-gnu-emacs@HIDDEN:bug#53798; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 5 Feb 2022 12:43:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 05 07:43:34 2022
Received: from localhost ([127.0.0.1]:34024 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nGKPd-0003Nv-PD
for submit <at> debbugs.gnu.org; Sat, 05 Feb 2022 07:43:34 -0500
Received: from lists.gnu.org ([209.51.188.17]:44992)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <triska@HIDDEN>) id 1nGKPc-0003No-4n
for submit <at> debbugs.gnu.org; Sat, 05 Feb 2022 07:43:32 -0500
Received: from eggs.gnu.org ([209.51.188.92]:34788)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <triska@HIDDEN>)
id 1nGKPV-0007wK-V7
for bug-gnu-emacs@HIDDEN; Sat, 05 Feb 2022 07:43:30 -0500
Received: from [78.47.144.35] (port=49832 helo=metalevel.at)
by eggs.gnu.org with esmtp (Exim 4.90_1)
(envelope-from <triska@HIDDEN>) id 1nGKPJ-0005qj-2m
for bug-gnu-emacs@HIDDEN; Sat, 05 Feb 2022 07:43:14 -0500
Received: from mt-mbpro.localdomain (localhost [127.0.0.1])
by metalevel.at (Postfix) with ESMTP id 9E7C59C73F
for <bug-gnu-emacs@HIDDEN>; Sat, 5 Feb 2022 13:42:59 +0100 (CET)
Received: by mt-mbpro.localdomain (Postfix, from userid 501)
id 42C1614E449D; Sat, 5 Feb 2022 13:42:58 +0100 (CET)
From: Markus Triska <triska@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 27.1; OSX: (redisplay) does not reliably redisplay
Date: Sat, 05 Feb 2022 13:42:58 +0100
Message-ID: <m2y22pfprh.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, RDNS_NONE=0.793,
SPF_HELO_NONE=0.001, SPF_NONE=0.001,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -2.3 (--)
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: -3.3 (---)
To reproduce this issue, please start Emacs with:
$ emacs -Q
and evaluate the following form:
(while t
(insert "\n" (make-string 50 ?a))
(redisplay)
(sit-for 0.1))
At first, this works completely as intended: We see a growing number of
lines in the buffer, and we are shown each fresh line as it appears:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
...
However, as soon as any key is pressed, the output becomes erratic in
the sense that for long stretches of time, we see no new lines at all,
and then several of them appear immediately at the same time.
The snippet uses (redisplay) after writing each line in order to show
the line as it appears. I therefore expect to continue to see, also when
a key is pressed, each line immediately after it is written in the
buffer, not batches of multiple lines to be shown after several of them
have already been written. Is there any way to obtain this behaviour?
Thank you a lot!
All the best,
Markus
In GNU Emacs 27.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scroll bars)
of 2020-12-12 built on mt-macbook
Windowing system distributor 'The X.Org Foundation', version 11.0.11502000
System Description: Mac OS X 10.11.3
Configured using:
'configure --prefix=/opt/local --disable-silent-rules --without-ns
--without-dbus --without-gconf --without-libotf --without-m17n-flt
--with-gmp --with-gnutls --with-json --with-xml2 --with-modules
--infodir /opt/local/share/info/emacs --with-x-toolkit=lucid
--without-xaw3d --without-imagemagick --with-xpm --with-jpeg
--with-tiff --with-gif --with-png --with-lcms2 --without-rsvg
--with-xft 'CFLAGS=-pipe -Os -arch x86_64'
CPPFLAGS=-I/opt/local/include 'LDFLAGS=-L/opt/local/lib
-Wl,-headerpad_max_install_names -lfreetype -lfontconfig -Wl,-no_pie
-arch x86_64''
Configured features:
XPM JPEG TIFF GIF PNG GSETTINGS GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2
FREETYPE HARFBUZZ XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM
MODULES THREADS JSON PDUMPER LCMS2 GMP
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Markus Triska <triska@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#53798; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.