From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#53798: 27.1; OSX: (redisplay) does not reliably redisplay Date: Sat, 05 Feb 2022 20:38:15 +0200 Message-ID: <83a6f517mw.fsf@gnu.org> References: <83leyp1mte.fsf@gnu.org> <87tuddxlwb.fsf@metalevel.at> <83ee4h196x.fsf@gnu.org> <87h79duq77.fsf@metalevel.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11764"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53798@debbugs.gnu.org To: Markus Triska Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 05 19:43:25 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 1nGQ1t-0002oZ-0a for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Feb 2022 19:43:25 +0100 Original-Received: from localhost ([::1]:57686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGQ1r-0000UA-LW for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Feb 2022 13:43:23 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58888) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGPye-000067-BX for bug-gnu-emacs@gnu.org; Sat, 05 Feb 2022 13:40:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41682) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nGPyc-0006LD-4b for bug-gnu-emacs@gnu.org; Sat, 05 Feb 2022 13:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nGPyb-00045A-Uo for bug-gnu-emacs@gnu.org; Sat, 05 Feb 2022 13:40:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Feb 2022 18:40:01 +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.164408635815634 (code B ref 53798); Sat, 05 Feb 2022 18:40:01 +0000 Original-Received: (at 53798) by debbugs.gnu.org; 5 Feb 2022 18:39:18 +0000 Original-Received: from localhost ([127.0.0.1]:35579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGPxu-000446-H9 for submit@debbugs.gnu.org; Sat, 05 Feb 2022 13:39:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nGPxs-00043t-T6 for 53798@debbugs.gnu.org; Sat, 05 Feb 2022 13:39:17 -0500 Original-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 ) 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==; Original-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 ) id 1nGPxJ-0001fI-DS; Sat, 05 Feb 2022 13:38:47 -0500 In-Reply-To: <87h79duq77.fsf@metalevel.at> (message from Markus Triska on Sat, 05 Feb 2022 19:24:28 +0100) 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:226085 Archived-At: > From: Markus Triska > Cc: 53798@debbugs.gnu.org > Date: Sat, 05 Feb 2022 19:24:28 +0100 > > 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. 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.