From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25606: [DRAFT PATCH 2/2] Signal list cycles in =?UTF-8?Q?=E2=80=98length=E2=80=99?= etc. Date: Fri, 03 Feb 2017 09:55:57 +0200 Message-ID: <83efzfvhbm.fsf@gnu.org> References: <20170201235622.30836-1-eggert@cs.ucla.edu> <20170201235622.30836-2-eggert@cs.ucla.edu> <83wpd8v6x8.fsf@gnu.org> <0a01d2ce-ef3e-7db0-6854-1b5e46d49be4@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1486108631 24121 195.159.176.226 (3 Feb 2017 07:57:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 3 Feb 2017 07:57:11 +0000 (UTC) Cc: 25606@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 03 08:57:06 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZYjy-00062m-4o for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Feb 2017 08:57:06 +0100 Original-Received: from localhost ([::1]:60648 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZYk3-0000Co-Qa for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Feb 2017 02:57:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZYjx-0000CY-Cw for bug-gnu-emacs@gnu.org; Fri, 03 Feb 2017 02:57:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZYju-0008SZ-8w for bug-gnu-emacs@gnu.org; Fri, 03 Feb 2017 02:57:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56243) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cZYju-0008SR-5E for bug-gnu-emacs@gnu.org; Fri, 03 Feb 2017 02:57:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cZYjt-0002vh-Uf for bug-gnu-emacs@gnu.org; Fri, 03 Feb 2017 02:57: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: Fri, 03 Feb 2017 07:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25606 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 25606-submit@debbugs.gnu.org id=B25606.148610858111212 (code B ref 25606); Fri, 03 Feb 2017 07:57:01 +0000 Original-Received: (at 25606) by debbugs.gnu.org; 3 Feb 2017 07:56:21 +0000 Original-Received: from localhost ([127.0.0.1]:54442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZYjE-0002um-Su for submit@debbugs.gnu.org; Fri, 03 Feb 2017 02:56:21 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZYjD-0002uZ-KF for 25606@debbugs.gnu.org; Fri, 03 Feb 2017 02:56:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZYj5-0008AG-4S for 25606@debbugs.gnu.org; Fri, 03 Feb 2017 02:56:14 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZYj5-0008AC-0u; Fri, 03 Feb 2017 02:56:11 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2882 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cZYj4-0001Dq-7H; Fri, 03 Feb 2017 02:56:10 -0500 In-reply-to: <0a01d2ce-ef3e-7db0-6854-1b5e46d49be4@cs.ucla.edu> (message from Paul Eggert on Thu, 2 Feb 2017 15:01:16 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:128907 Archived-At: > Cc: 25606@debbugs.gnu.org > From: Paul Eggert > Date: Thu, 2 Feb 2017 15:01:16 -0800 > > On 02/02/2017 09:28 AM, Eli Zaretskii wrote: > > > could we please have tests for these functions? > Good point, I'll look into adding some. Thanks. > > I think we shouldn't second-guess users this way, and > > should always leave them the possibility of interrupting a possibly > > prolonged calculation. > > Sure, but we shouldn't insert maybe_quit calls after every nanosecond's > worth of computation; that'd be overkill and would slow down Emacs > unnecessarily. No, not that frequently, I agree. So perhaps rarely_quit is a better possibility in these places. But in general, data structures on which these primitives work could be rather large, and processing them could take a tangible amount of time. Moreover, on a memory-starved system or a system under heavy computational load, the processing could take a long elapsed time even if the CPU time used by Emacs is very small. Users get annoyed by elapsed time, because that's what they perceive. So making these uninterruptible except in case of glaring bugs sounds like losing a valuable fire escape to me. > We should insert a maybe_quit call only when Emacs may have done > enough computation that it would be annoying if the user typed C-g > and Emacs did not respond for that period of time. Sure. But do we have a reliable device to measure this quantity? Once again, the elapsed time tends to annoy users regardless of the real computational resources used by Emacs. IOW, the removal is probably justified for 90% of use cases, maybe even more, but it could be a problem for a small fraction of use cases. And since quitting is a kind of zero-level troubleshooting in Emacs, I think we should be biased towards those rare cases here.