From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#70221: [PATCH] New function `funcall-later` Date: Sat, 06 Apr 2024 11:46:28 -0400 Message-ID: References: <86zfu73smn.fsf@gnu.org> <864jce34yv.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35253"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 70221@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 06 17:47:12 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 1rt8G7-0008vJ-QP for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Apr 2024 17:47:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rt8Ft-0000QP-Eo; Sat, 06 Apr 2024 11:46:57 -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 1rt8Fs-0000Np-EF for bug-gnu-emacs@gnu.org; Sat, 06 Apr 2024 11:46:56 -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 1rt8Fs-0005Jo-0e for bug-gnu-emacs@gnu.org; Sat, 06 Apr 2024 11:46:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rt8Fx-0005G3-UM for bug-gnu-emacs@gnu.org; Sat, 06 Apr 2024 11:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Apr 2024 15:47:01 +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.171241841220178 (code B ref 70221); Sat, 06 Apr 2024 15:47:01 +0000 Original-Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 15:46:52 +0000 Original-Received: from localhost ([127.0.0.1]:40649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rt8Fn-0005FO-Gi for submit@debbugs.gnu.org; Sat, 06 Apr 2024 11:46:51 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rt8Fk-0005Ea-SR for 70221@debbugs.gnu.org; Sat, 06 Apr 2024 11:46:50 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3B5F180BC1; Sat, 6 Apr 2024 11:46:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1712418395; bh=HCA1JFhWzjcDJjsL+U4H2rU1HM2K7kJrf34ea5HSzE4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hP9610NnlKKzhJt+TGwSuuUE2VEzyEG1YyujVqW8YInIswYq7uffKLTw2blz8QWzy lnpLkqGGyaQH6Q1ykinUn6YsCZwQK9cZ1ehY1wxlfQERx4Cr2R8o8zyjBs5vaxuIo1 0o/MuRo8dYPl6+8apb5pPtkeYu8K0MJFHRSXIMWDAZsnJwA81XFGSCmy+SSihiESwp idZeM8v3Y7nq8Tyz9cxHerQesZ63WMfWJ70Z3wJKOzh/fQG8/2Egd+pbidtlzarlgi dcuVF5Q3dAjxTM+6Ql3ZUjcPoEqxkdsOy3+d/vkyYLUgkNGSUyE+DK5J7McYlBKawr pS/48ZdZs03yA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 21E79805E6; Sat, 6 Apr 2024 11:46:35 -0400 (EDT) Original-Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 00CA612030C; Sat, 6 Apr 2024 11:46:34 -0400 (EDT) In-Reply-To: <864jce34yv.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 Apr 2024 18:07:04 +0300") 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:282802 Archived-At: > 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. >> 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. > 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. > You are converting several places to using this new facility, so the > prudent thing, in a program as complex and devious as Emacs, is to > keep compatibility even if our hubris tempts us to think we are > smarter. Bitter experience has taught me that we are not smarter, so > I now prefer humility instead. Ah, you're talking about the second patch. Yes, I'm not really sure we want that one. I included it more to show that there is interest in such a facility, but I don't think the risk of breakage justifies installing it. >> AFAICT we don't document anywhere that `deactive-mark` is bound >> around timers, so I guess fixing that would be the best way to document >> the difference. > I mean where we explain the differences between zero-delay timers and > funcall-later. We _will_ explain those, right? As soon as we've figured the main "when is it run" question =F0=9F=99=82 >> That's the big question, really. E.g. I currently use `funcall-later` >> in `track-changes.el` and in `futur.el`. I use it because it's handy. >> But fundamentally those two need different things: [...] > 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. - It might mean that `funcall-later` is ill-defined and should be rejected, or split into two, or should take extra arguments, or ... Stefan