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.devel Subject: Re: A whole lotta auto-saving going Date: Mon, 11 Jan 2021 18:54:34 +0200 Message-ID: <831rerfm7p.fsf@gnu.org> References: <8735zdyly0.fsf@gnus.org> <87y2h1vyhq.fsf@gnus.org> <877dokq0fz.fsf@gnus.org> <83y2h0g0rk.fsf@gnu.org> <83k0sjfrad.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39984"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, aaronjensen@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 11 17:55:14 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 1kz0TJ-000AHm-Hu for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 17:55:13 +0100 Original-Received: from localhost ([::1]:50984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kz0TI-0001Ip-KI for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 11:55:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kz0SY-0000ip-5f for emacs-devel@gnu.org; Mon, 11 Jan 2021 11:54:27 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39992) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kz0SX-0003Nw-BB; Mon, 11 Jan 2021 11:54:25 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3787 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kz0SW-00069A-Nx; Mon, 11 Jan 2021 11:54:25 -0500 In-Reply-To: (message from Stefan Monnier on Mon, 11 Jan 2021 11:00:04 -0500) 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:262921 Archived-At: > From: Stefan Monnier > Cc: larsi@gnus.org, aaronjensen@gmail.com, emacs-devel@gnu.org > Date: Mon, 11 Jan 2021 11:00:04 -0500 > > > 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`. Do we get to where that causes redisplay in this case? > > 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? > 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? 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?