From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Markus Triska Newsgroups: gmane.emacs.bugs Subject: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay Date: Sat, 05 Feb 2022 19:24:28 +0100 Message-ID: <87h79duq77.fsf@metalevel.at> References: <83leyp1mte.fsf@gnu.org> <87tuddxlwb.fsf@metalevel.at> <83ee4h196x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14775"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: 53798@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 05 19:27:05 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nGPm5-0003cq-4u for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Feb 2022 19:27:05 +0100 Original-Received: from localhost ([::1]:51422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGPm3-0003ww-UW for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Feb 2022 13:27:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57288) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGPk7-0002Li-0D for bug-gnu-emacs@gnu.org; Sat, 05 Feb 2022 13:25:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41667) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nGPk6-0004QL-My for bug-gnu-emacs@gnu.org; Sat, 05 Feb 2022 13:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nGPk6-0003iE-Kx for bug-gnu-emacs@gnu.org; Sat, 05 Feb 2022 13:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Feb 2022 18:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53798 X-GNU-PR-Package: emacs Original-Received: via spool by 53798-submit@debbugs.gnu.org id=B53798.164408547214226 (code B ref 53798); Sat, 05 Feb 2022 18:25:02 +0000 Original-Received: (at 53798) by debbugs.gnu.org; 5 Feb 2022 18:24:32 +0000 Original-Received: from localhost ([127.0.0.1]:35564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGPjb-0003hN-MD for submit@debbugs.gnu.org; Sat, 05 Feb 2022 13:24:31 -0500 Original-Received: from [78.47.144.35] (port=45950 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGPjZ-0003hE-BK for 53798@debbugs.gnu.org; Sat, 05 Feb 2022 13:24:29 -0500 Original-Received: by metalevel.at (Postfix, from userid 1000) id 1B6529C753; Sat, 5 Feb 2022 19:24:28 +0100 (CET) In-Reply-To: <83ee4h196x.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Feb 2022 20:04:38 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:226084 Archived-At: Eli Zaretskii 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