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.devel Subject: Re: A whole lotta auto-saving going Date: Mon, 11 Jan 2021 11:00:04 -0500 Message-ID: References: <8735zdyly0.fsf@gnus.org> <87y2h1vyhq.fsf@gnus.org> <877dokq0fz.fsf@gnus.org> <83y2h0g0rk.fsf@gnu.org> <83k0sjfrad.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="38913"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: larsi@gnus.org, aaronjensen@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 11 17:02:59 2021 Return-path: Envelope-to: ged-emacs-devel@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 1kyzek-0009zO-SI for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 17:02:58 +0100 Original-Received: from localhost ([::1]:43060 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kyzej-0002JO-6v for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 11:02:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59966) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kyzcE-0000yZ-CS for emacs-devel@gnu.org; Mon, 11 Jan 2021 11:00:22 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24231) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kyzc2-00014t-Sz; Mon, 11 Jan 2021 11:00:21 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 21AEB101AA5; Mon, 11 Jan 2021 11:00:08 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 32A53100216; Mon, 11 Jan 2021 11:00:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1610380806; bh=gCyToFHvxvDC3nB+Aij75xFwK8Lvew4tQ0/Pnz4ZcZU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OAG8UdU3RU7TS/oC+nT+wRimv+EWS4YoATdy8u67ufnn2kX+YHSO+5YunaZqGvFZt w5T7joJ04VCSBwyqVE1JtLhatGhQ1DwhYe0O4uHCBvemXdtYeo3edZand5KdPsm+78 E1g5tkTju9ylIeKy1biIYafBoR9zfwJ6lNAWFfIogT7Qd2MdclxRoVknFxU27Dkw0g 9rZRwnpa+PgGcJ8j14gYu1UNHbBprgwH0ppKHX0UyJxugUupxvBpLj8n3FIBF7AJmI kFm4nn7oXnf+847OyyhzW4YKP7ayd1aHrt2dXVfA0inTi9syhnLSP/oZrtloLoLj6q k9ZKL/UZxL+jA== Original-Received: from alfajor (unknown [45.72.224.181]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B640A12024D; Mon, 11 Jan 2021 11:00:05 -0500 (EST) In-Reply-To: <83k0sjfrad.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 11 Jan 2021 17:04:58 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262918 Archived-At: >> Does someone here understanding something of what >> `wait_reading_process_output` does and what it is expected to do? > You mean, in general? or in this specific case? Both. > The latter is described by the comment above this fragment. It gives an idea, yes, but not enough to know what is expected in the specific case that corresponds to how it's called from `sit_for`. >> Why does it exit here before the end of the timeout? IIUC it is >> supposed to exit as soon as we got some output from `wait_proc`, but in >> this case `wait_proc` is NULL. Is it also supposed to exit when some >> process output arrives? If so, shouldn't `sit_for` wrap the call to >> `wait_reading_process_output` inside a loop to make sure we wait the >> whole timeout? > I think sitting for the entire period is undesirable, since receiving > output from a process might require redisplay. > In that case, waiting could make Emacs seem unresponsive or busy, > whereas it really isn't. But the `do_display` argument indicates that if redisplay is needed it can happen without returning from `wait_reading_process_output`. > I think a simple solution to this would be to check the time passed > after sit_for returns, and if some of the wait time is left, not call > auto-save. This would mimic what happened before the offending > changeset. The patch below implements that option. There's one other call to `sit_for` which can be affected: tem0 = sit_for (Vecho_keystrokes, 1, 1); unbind_to (count, Qnil); if (EQ (tem0, Qt) && ! CONSP (Vunread_command_events)) echo_now (); I believe it's an improvement there as well. Stefan diff --git a/src/dispnew.c b/src/dispnew.c index 36a6dd8a09..39adbb2229 100644 --- a/src/dispnew.c +++ b/src/dispnew.c @@ -6049,7 +6049,9 @@ DEFUN ("sleep-for", Fsleep_for, Ssleep_for, 1, 2, 0, READING is true if reading input. If DISPLAY_OPTION is >0 display process output while waiting. If DISPLAY_OPTION is >1 perform an initial redisplay before waiting. -*/ + + Returns a boolean Qt if we waited the full time and returns Qnil if the + wait was interrupted by incoming process output or keyboard events. */ Lisp_Object sit_for (Lisp_Object timeout, bool reading, int display_option) @@ -6110,8 +6112,9 @@ sit_for (Lisp_Object timeout, bool reading, int display_option) gobble_input (); #endif - wait_reading_process_output (sec, nsec, reading ? -1 : 1, do_display, - Qnil, NULL, 0); + int nbytes + = wait_reading_process_output (sec, nsec, reading ? -1 : 1, do_display, + Qnil, NULL, 0); if (reading && curbuf_eq_winbuf) /* Timers and process filters/sentinels may have changed the selected @@ -6120,7 +6123,7 @@ sit_for (Lisp_Object timeout, bool reading, int display_option) buffer to start with). */ set_buffer_internal (XBUFFER (XWINDOW (selected_window)->contents)); - return detect_input_pending () ? Qnil : Qt; + return (nbytes > 0 || detect_input_pending ()) ? Qnil : Qt; }