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 13:00:33 -0500 Message-ID: References: <8735zdyly0.fsf@gnus.org> <87y2h1vyhq.fsf@gnus.org> <877dokq0fz.fsf@gnus.org> <83y2h0g0rk.fsf@gnu.org> <83k0sjfrad.fsf@gnu.org> <831rerfm7p.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="985"; 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 19:02:19 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 1kz1WC-00006E-Q5 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 19:02:16 +0100 Original-Received: from localhost ([::1]:35702 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kz1W9-00015i-Vp for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 13:02:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33678) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kz1Ui-0000Xq-35 for emacs-devel@gnu.org; Mon, 11 Jan 2021 13:00:44 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kz1Ud-00072V-5b; Mon, 11 Jan 2021 13:00:43 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2387E101AA5; Mon, 11 Jan 2021 13:00:37 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6C7E5100225; Mon, 11 Jan 2021 13:00:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1610388035; bh=miDNJRsqg2lGKBSnSGI44hFuO9ei7uA4NSRgX13lRqo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=ThBk4aRL3t9yP6kX4JUP53L22527IEFgUL+9Y3PY0Y4YQhof7lMDJ8rO6m3akYlfc H3AgRJivM/ie/ssGhg3cGB06y/yBAKumVL++GRcunfYlFDi6KUaFgwDkE5WAEMAMHU 5u2T01iWpdoc1QalBq/bqWIglqLD//pZ4rk63YVMIE7ntWN66YIJ9HkoVF97NanGGG M3m4vw3uQasWo1JSDYxecOGFmvbqniCfy7N/lDvRcvDMnnlwX0ImAFRo+E1Mg0zg7f /xdowm5CqyCS9P/XPDTIOPx62rt2w9UmD6QjqEqrhFTuzXqO/TylYrMpMxgnc9zzZE hgaPmFe/1X2Eg== Original-Received: from alfajor (unknown [45.72.224.181]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 28FBF1202F4; Mon, 11 Jan 2021 13:00:35 -0500 (EST) In-Reply-To: <831rerfm7p.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 11 Jan 2021 18:54:34 +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:262925 Archived-At: >> But the `do_display` argument indicates that if redisplay is needed it >> can happen without returning from `wait_reading_process_output`. > Do we get to where that causes redisplay in this case? I don't know, but we should because the code does pass a true value for this parameter. >> > 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. > Thanks. > I see you look at the number of bytes read, but what about the case > that a process exited? I don't know anything about that case, sorry (i.e. I don't know if it causes `wait_reading_process_output` to exit early). So ... let me test it. Hmm... interesting. I used the current `master` code with the following base test case: src/emacs -Q --eval '(start-process "toto" "*scratch*" "sh" "-c" "while sleep 1; do echo hi; done")' ~/tmp/foo.c This triggers the problem where auto-save is done pretty much after every keystroke (with ~1s delay). But if I change that to: src/emacs -Q --eval '(add-hook `post-command-hook (lambda () (start-process "toto" "*scratch*" "sh" "-c" "sleep 1; echo hi")))' ~/tmp/foo.c then the problem doesn't seem to occur any more (or rather it still does, but more rarely, with a pattern I have trouble discerning). It does occur, OTOH with: src/emacs -Q --eval '(add-hook `post-command-hook (lambda () (start-process "toto" "*scratch*" "sh" "-c" "sleep 1; echo hi; sleep 1")))' ~/tmp/foo.c So it looks like running sentinels does not trigger this problem (it may even avoid it if the sentinel is run "at the same time" as we receive output). With the patch applied, none of the above test cases exhibit the problem of "A whole lotta auto-saving going". >> 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. > > Why do you believe that? Because I remember noticing that the echo-keystrokes output sometimes was displayed earlier than expected (and that it seemed related to process output). > It's a different use case, and I don't think we saw any adverse > effects there from the removal of the buffer-switch "event". > Are there any adverse effects? The fact that echo-keystrokes were displayed earlier than expected was not a serious issue, so I didn't bother to report it. But I do think it's an adverse effect. This said, the current patch has the inverse effect (just like the old code): auto-save (and echo-keystrokes) can be delayed (potentially indefinitely) by process output since the `sit_for` call will only return nil if we waited until timeout without being interrupted by any process output. That's why I think in the long run it would be good to change `sit_for` so it actually does wait the specified time even when process output comes in (just like The Elisp `sit-for` function does). Stefan