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.bugs Subject: bug#70221: [PATCH] New function `funcall-later` Date: Sat, 06 Apr 2024 19:15:51 +0300 Message-ID: <86wmpa1n7s.fsf@gnu.org> References: <86zfu73smn.fsf@gnu.org> <864jce34yv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33801"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70221@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 06 18:17:16 2024 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 1rt8jE-0008aN-1J for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Apr 2024 18:17:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rt8iw-0007yc-41; Sat, 06 Apr 2024 12:16:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rt8iv-0007y9-EV for bug-gnu-emacs@gnu.org; Sat, 06 Apr 2024 12:16:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rt8iv-0003sW-3Z for bug-gnu-emacs@gnu.org; Sat, 06 Apr 2024 12:16:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rt8j1-0002UT-7b for bug-gnu-emacs@gnu.org; Sat, 06 Apr 2024 12:17:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Apr 2024 16:17:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70221 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70221-submit@debbugs.gnu.org id=B70221.17124201858655 (code B ref 70221); Sat, 06 Apr 2024 16:17:03 +0000 Original-Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 16:16:25 +0000 Original-Received: from localhost ([127.0.0.1]:40798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rt8iA-0001nc-3r for submit@debbugs.gnu.org; Sat, 06 Apr 2024 12:16:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rt8i6-0001aJ-06 for 70221@debbugs.gnu.org; Sat, 06 Apr 2024 12:16:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rt8hu-00034D-8D; Sat, 06 Apr 2024 12:15:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Mz/5I3axeHpnAZyTQKHV3tKgXygN4dACMGAvqIi+lYQ=; b=cIVPLhBUGV3y 86z+lXTwf781qU6kh9BS9n1aJpf3/rsy1W7TUtnGvJIazsqCk0wRmEa6tpKHqVHLdtOh38aZKugsm ugNrQe9nVxFRIgyzyRSOk/P3P3vVgQ+oUhm/RFyU/lYGGK1UOxUNvQAxlMbXaV6daB52WSYakW6My 6Uzc51Kd8vQrYBY2SkXdEPEnekTjqdMEuv5s4pPuBsjYdR13QuY58/Kr/muInly7Lec503PCCBMFm OL9n4HTIYuwKpUJpKB9Ed5wrXzUo96rZb/ysHQtqFtCaORGOIp2opeJ48GL6Ey78zJEz8iVa3jvdJ 6QRTG4javTKwSsefvKJO2Q==; In-Reply-To: (message from Stefan Monnier on Sat, 06 Apr 2024 11:46:28 -0400) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282804 Archived-At: > From: Stefan Monnier > Cc: 70221@debbugs.gnu.org > Date: Sat, 06 Apr 2024 11:46:28 -0400 > > > timer-event-handler uses condition-case-unless-debug, so I don't see a > > problem with timers, and I think your use of safe_call2 was not a > > mistake. > > `condition-case-unless-debug` is very different from `safe_calln`. > It doesn't prevent non-local exits nor prevent showing a debugger. It catches errors, doesn't it? That's what bothers me with CALLN. > >> I can't see any good reason why we'd need to protect the > >> C code from non-local exits in `timer_check_2`. > > Because it will prevent timers from being called? > > Why would it? after the non-exit is caught somewhere up the stack, we'd > eventually come back to `timer_check_2` and run the timer then. Unless the same buggy funcall-later is again in the list, right? Or do we have a machinery to disable them, like we disable faulty timers? > > From my POV, any code that runs from some background facility must > > inhibit QUIT, because the user can type C-g at any moment. > > Agreed, and `funcall-later` doesn't run it "in the background", it runs > it at the end of the current code. How is this different from running timers? > > I don't think I disagree with what you write, but I fail to see how it > > is relevant to the need to explain better what is that "next > > convenient time" when the function will run. In particular, I don't > > see how the different uses of funcall-later affect that "next > > convenient time". > > It's relevant in two ways: > > - It determines which part of the time-behavior we should consider as > something we want to document and guarantee, as opposed to the part > which is incidental and which we may prefer to document as not to be > relied on. I'm not sure I understand where you are going with this. It seems very easy to tell when the delayed functions will be called, so why are we arguing? > - It might mean that `funcall-later` is ill-defined and should be > rejected, or split into two, or should take extra arguments, or ... If the implementation changes, we will change the documentation to go along. But Lisp programmers who want to use this facility must have a pretty good idea of when the delayed code will be called, or else they are in for a bumpy ride.