From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output Date: Fri, 11 Sep 2020 12:22:45 -0400 Message-ID: References: <83sh1gzdey.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="11828"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 32986@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 11 18:23:12 2020 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 1kGlpP-0002yR-JC for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Sep 2020 18:23:11 +0200 Original-Received: from localhost ([::1]:35404 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGlpO-0006AD-IU for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Sep 2020 12:23:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58466) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGlpG-00068v-Fo for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2020 12:23:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kGlpG-0007wv-64 for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2020 12:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kGlpG-0000T9-1S for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2020 12:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Sep 2020 16:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32986 X-GNU-PR-Package: emacs Original-Received: via spool by 32986-submit@debbugs.gnu.org id=B32986.15998413771778 (code B ref 32986); Fri, 11 Sep 2020 16:23:01 +0000 Original-Received: (at 32986) by debbugs.gnu.org; 11 Sep 2020 16:22:57 +0000 Original-Received: from localhost ([127.0.0.1]:45234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kGlpA-0000Sc-Uf for submit@debbugs.gnu.org; Fri, 11 Sep 2020 12:22:57 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:35031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kGlp8-0000SO-GX for 32986@debbugs.gnu.org; Fri, 11 Sep 2020 12:22:55 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 34386100250; Fri, 11 Sep 2020 12:22:49 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F20FE1001D2; Fri, 11 Sep 2020 12:22:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1599841366; bh=XUBGmk+wINhoEtGz7zE8PpSkFrnRxFWDqdnis9ULMMo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=oLbvZnL1cbPsQRcqiFLlYHBBgi9q5YvR4v2+xnetVHOc3j0EzHT4tdTdBp5H2XkUC lqz4GHWNUQXcvy5p85ioEZ27rFvQk7vFLyOoYyqaAv4H/FRThs1IKO1NUlBm8+171I 33o1Dcnj5BjQwPwQ3e5fs8/ivKOElg/TSMSwzf7/x9bTO85mtJOefssk4Pkihh2wa7 4ZWenIjt/Tda72/H9PYKc1ePe59RytWowsPMK4cvfPC+G7G7jdZ+1w+0H4qOviMxyW XRKOerLWEdrD1k6G4wPxYwErH4ax1K9R1/5zS0Kh8xoMFIdGNRpDKbUa75/58PIYnp vGP9k0bdu4uhw== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C0EFC12064D; Fri, 11 Sep 2020 12:22:46 -0400 (EDT) In-Reply-To: <83sh1gzdey.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 08 Oct 2018 18:05:57 +0300") 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:187849 Archived-At: >> I would expect while-no-input to break out of accept-process-output very >> quickly after user keyboard input. These expectations are met except >> for some situations. > I think your expectations are incorrect. I beg to differ. > My expectations are that if you call accept-process-output with > a timeout of 30 sec, then while-no-input will return after 30 sec plus > a small delay. I'm OK if you don't consider it a "bug", but it does not satisfy the needs behind `while-no-input`, so I think it's definitely something that we should aim to improve. The needs behind `while-no-input` often fail to be satisfied by our C code, so this is not the first nor the last problem with it. But if we can fix this case, Emacs will be better for it. > First, one basic fact: accept-process-output calls > wait_reading_process_output in a way that instructs it not to wait for > keyboard input, you can see that clearly in the code (read_kbd is > passed as zero). What happens if we change this? > This means that wait_reading_process_output will > call pselect with the timeout of 30 sec (in your case), and will wait > that long before it returns (unless there's a subprocess that gives us > some stuff). So why would you expect while-no-input that calls > accept-process-output with that timeout to return earlier? The question is not "given the current implementation, why should it behave differently". I expect it to return immediately because Emacs is just there sitting idly so there is no good reason why it shouldn't also check keyboard input at the same time as it's checking process output. > Therefore, to see the 30-sec delay, you need: > > . stop all timers, which in "emacs -Q" means: > . disable blink-cursor-mode > . disable global-eldoc-mode > . disable font-lock-mode > . cancel the undo--auto-bindary-timer (I did that via list-timers) > . type "C-u C-x C-e", wait for a few seconds, and only then type SPC > > If I do all of the above, I see 30 sec plus a small delay every time I > run your 2nd test. IOW you cannot reliably expect it to wait 30s, so changing it so it returns more promptly won't break any code. That's good news. All we need is for someone to come up with a patch. Stefan