Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 70221) by debbugs.gnu.org; 7 Apr 2024 05:28:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 07 01:28:42 2024 Received: from localhost ([127.0.0.1]:41375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rtL58-00081b-9O for submit <at> debbugs.gnu.org; Sun, 07 Apr 2024 01:28:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rtL55-00081O-VZ for 70221 <at> debbugs.gnu.org; Sun, 07 Apr 2024 01:28:40 -0400 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 <eliz@HIDDEN>) id 1rtL4t-0007GN-Hs; Sun, 07 Apr 2024 01:28:27 -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=A1JwZLgLXhEyNCfxG1UoGHujEsVB8Hymk4tHw62yTqw=; b=lZE+aqaeljqv xH7MEi4o2TWb2tJYoWzsCo5DMHIti4tS0gKQTjcmAelRf8O54tX9eWwkInNMYX/gjgnUEOPMdpJjj /4vka03G5crlnIkv4arK34hKun+9ZNaLxmBpqLAgrW+7R89Ty8lzH6QSPLJLjY4CzCdNqefDFMBx0 VQgwNJlSZG7hqaxzuS7W5cktsjUJcBqgMaq7JkS37C2djo+2+JODEYYa90gdfvFxtFQWfN/x3+/Ts TuQOZ/VB7B4qUu9cWhYKVxwV/wPJfTaSZrtRTF9x/ah0plv7BB/EXj0bVUSA+L7M8zSVLv0iGokmU kWmDB2oSm/++6xX2zhtuGQ==; Date: Sun, 07 Apr 2024 08:28:25 +0300 Message-Id: <86r0fh213a.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvh6gegtsp.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 06 Apr 2024 16:00:53 -0400) Subject: Re: bug#70221: [PATCH] New function `funcall-later` References: <jwvbk6nh9c7.fsf@HIDDEN> <86zfu73smn.fsf@HIDDEN> <jwvy19qiozw.fsf-monnier+emacs@HIDDEN> <864jce34yv.fsf@HIDDEN> <jwv4jceik0g.fsf-monnier+emacs@HIDDEN> <86wmpa1n7s.fsf@HIDDEN> <jwvh6gegtsp.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70221 Cc: 70221 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 70221 <at> debbugs.gnu.org > Date: Sat, 06 Apr 2024 16:00:53 -0400 > > >> `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? > > What's good about it? > > > That's what bothers me with CALLN. > > With CALLN the errors don't get caught by `safe_calln` so they get > caught further up the stack, which seems fine by me. > What problem/scenario are you thinking about? That we throw to top-level from a normal processing loop. Why should we not prevent that if we can? Why are you so objected to doing what we have always done there? > >> >> 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? > > No: we bump it off the list before the CALLN, specifically to > avoid this problem. They don't auto-repeat like some timers. The Lisp program that initiated it could initiate another one soon enough. Why risk that when the solution is so easy? I really don't understand your objections here. Is there any harm that can possibly be done by catching errors, like timers do? If not, why not do it? > >> > 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? > > Non-0s timers are run in the context of some future command (or in the > middle of "idle" time). `funcall-later` are run before we get to idle > time or to the next user input The funcall-later functions are run in exactly the same context. Look at the code: they are called inside the same loop in timer_check_2. So the context is exactly the same. > so if the user hits C-g during them, it's no different from hitting > C-g during the main part of the command. It's realy more like > `post-command-hook` (incidentally, I've been thinking that maybe we > should call `internal--run-pending-funcalls` when we run > `post-command-hook`). Whatever happens with zero timers happens also with funcall-later functions. So the same considerations apply. From the user POV, Emacs is idle, so the user can press C-g at any moment. E.g., it is customary to press C-g when Emacs sits at the prompt in the minibuffer: both timers and funcall-later functions can be run at that time. > >> - 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? > > I'm not sure the current implementation provides the behavior we want. > So I think it's worthwhile thinking about what it is that we want. > E.g. another implementation could be to have a separate thread running > those functions. Or as mentioned above we could run them from > `post-command-hook`. ... As long as the code is on the branch, I don't really care. But the moment it lands on master, it should have the proper documentation, and if by that time the implementation doesn't change, I insist on saying something about when these functions are called, because I think it's important. If the implementation does change, I will, of course, revisit my opinion (hopefully, during the review of the modified code that is to follow).
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.
Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 20:01:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 16:01:13 2024
Received: from localhost ([127.0.0.1]:41006 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rtCDw-0003DZ-BH
for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 16:01:13 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3149)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1rtCDr-0003CQ-QS
for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 16:01:10 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D207880C88;
Sat, 6 Apr 2024 16:00:55 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1712433654;
bh=1/diFS5+SttDUoti+GjwqHB/M48Odn3/KBpZNNalKqw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=T/EtbYOooix2m08NCH88v0l6x88v8EA8o3ebp6pbevKSbwZt9tKwkDHKlcsMmgYDd
f1M3DZj25uvTDaqYHcHM2bbaRwlWDv3JLr2wvllzsXfFwyb4MJW573N2qdDW8Y+rtC
CA9kMeXcCcGHERIPwpjBqgNKRqOxOOK2aMX59EURntM0EUmezvsiiKGV7MSeCsX2QM
stYgly+ODz5s1PHA+Qml7C/RvMh17YQLjqZma1cegvIUMksiiTR0KX1958aozA43mz
BWZmCidhNYOmPpe8s+lgBVcTlE3cO5mSbPzL3ObwV8+15kGy6stexRjIIcyt9jCxXR
IDtaEyW10fSPw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D7366808F9;
Sat, 6 Apr 2024 16:00:54 -0400 (EDT)
Received: from pastel (unknown [45.72.201.215])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B5E1D120611;
Sat, 6 Apr 2024 16:00:54 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#70221: [PATCH] New function `funcall-later`
In-Reply-To: <86wmpa1n7s.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 06 Apr
2024 19:15:51 +0300")
Message-ID: <jwvh6gegtsp.fsf-monnier+emacs@HIDDEN>
References: <jwvbk6nh9c7.fsf@HIDDEN> <86zfu73smn.fsf@HIDDEN>
<jwvy19qiozw.fsf-monnier+emacs@HIDDEN> <864jce34yv.fsf@HIDDEN>
<jwv4jceik0g.fsf-monnier+emacs@HIDDEN> <86wmpa1n7s.fsf@HIDDEN>
Date: Sat, 06 Apr 2024 16:00:53 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.116 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 70221
Cc: 70221 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> `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?
What's good about it?
> That's what bothers me with CALLN.
With CALLN the errors don't get caught by `safe_calln` so they get
caught further up the stack, which seems fine by me.
What problem/scenario are you thinking about?
>> >> 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?
No: we bump it off the list before the CALLN, specifically to
avoid this problem. They don't auto-repeat like some 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?
Non-0s timers are run in the context of some future command (or in the
middle of "idle" time). `funcall-later` are run before we get to idle
time or to the next user input, so if the user hits C-g during them,
it's no different from hitting C-g during the main part of the command.
It's realy more like `post-command-hook` (incidentally, I've been
thinking that maybe we should call `internal--run-pending-funcalls`
when we run `post-command-hook`).
>> - 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?
I'm not sure the current implementation provides the behavior we want.
So I think it's worthwhile thinking about what it is that we want.
E.g. another implementation could be to have a separate thread running
those functions. Or as mentioned above we could run them from
`post-command-hook`. ...
Stefan
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 17:32:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 13:32:44 2024 Received: from localhost ([127.0.0.1]:40918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rt9uF-0002tV-5S for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 13:32:44 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:51835) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1rt9uB-0002s6-HV for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 13:32:40 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id AB20132009F8; Sat, 6 Apr 2024 13:32:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 06 Apr 2024 13:32:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1712424745; x=1712511145; bh=JdBKNJ0vs1zagaicho23j6o+k9GVqafsyyy9fDB2YEw=; b= jaWQm9gSSZ7HRJ483pH8mQJTAqTsK19XA7mLewhK3CROYrVsnAkKtuarfsgkpKkB Wjk8FJg0iLl8l7qP9GOTzcAXeZZYUU9hogwh3RdW6cOPC9N3hxIJsW0M5qoUHxP/ p67FnraIdYb1XFUh7XnkPSaaIxMQQ9eNqHOpgV5lthHWtMinwgGz+NAtTVdo12td 0Py/YLXDD6JZJJO4q0+O8kNVXXl++AA1EnpU4QAJ+ktvi4IM3LWSDVl5Mw41wI+c wGLmyVgaLZzsm26JwWwmupfH9a4xTt2A0QvGtMSmLHkUpMfJzou8wDOr5TquSAWW UOgIFWJ1aDiJ76BSPWPIKw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1712424745; x= 1712511145; bh=JdBKNJ0vs1zagaicho23j6o+k9GVqafsyyy9fDB2YEw=; b=Z xXxZjy0vs61/pgFuR6Tvc1AaA+SbVqH55pczXmaaiiCx+QE28AUJMGlC5OnkW+18 s616co8NO4Aw3oOUw8w+A6ehNJwoyQbRHqfBkyGAL0lxm5taI3mh0ruJCYkZarXB Kyw3FPpvqlwCG+JnDXGBSgK3SnlRXhtg2ZtHxbLQcly29r0AmG4ETMMV2u3CQlIz 6y8RFTo8G0OhNN96LFZMe/9oGbBmJhJVptL2fnzq0gvPG2TGo0q1o/UtjespMnQ5 teldvWb0h9XM9INrejUwjrP1QmIp9s1HWZfDDxXdB6U6qxRUv8JLLHQ6fm/otvz2 81R6ke7ilAy/BTJv2DAsQ== X-ME-Sender: <xms:KIcRZi9X-zEa3i3notZt6_X8tPvBkr8U_K-yQIFO4e0aN9jII1AJ6g> <xme:KIcRZit1ooFHRW2p7yuu-qtwqj-ZMrkg2JmyBHYh4UxWLaMgCqWFGY4m7CJeLpQWg dLWomrK9SCQe7vRXn8> X-ME-Received: <xmr:KIcRZoDddGzEhxuqxX4qjQ6fS8xMx06DAve5JCk63CkLhO9_Ad-CDEAi31MCgkm_v_6g> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudegvddgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:KIcRZqe7pqO7wQhWLa8XITSBnjQqH8KUtNyNg7Hs7fejdP7zUCjjFQ> <xmx:KIcRZnO0zYbncnwfA2k3YBXD6JBDwXOLxBQP5PAIk-PHDj-n0Zxwpw> <xmx:KIcRZknDn8pvQDz9pLaA95fmOHAP2WWhk5Jw6Xf07MD_dPpIklaS_Q> <xmx:KIcRZptNY5ck2fhAB14-cxDG1fqSHRz5ZPxU_gsz9-7KU2KqMDfyzg> <xmx:KYcRZgrpF88idrFPe9K8XFyiYqwaF_je7CIj4R9GOCmXW9edoe9giOk83tvB> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 6 Apr 2024 13:32:23 -0400 (EDT) Message-ID: <e53292c9-06e0-4ca4-87ba-a90f3c2aa5f5@HIDDEN> Date: Sat, 6 Apr 2024 20:32:21 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#70221: [PATCH] New function `funcall-later` Content-Language: en-US To: Sean Whitton <spwhitton@HIDDEN>, 70221 <at> debbugs.gnu.org References: <jwvbk6nh9c7.fsf@HIDDEN> <87r0finbam.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <87r0finbam.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70221 Cc: Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 06/04/2024 11:30, Sean Whitton wrote: > Very nice. You could also update xref--ensure-default-directory. With a FIXME comment, maybe. xref is in "core elpa", so not yet.
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 16:16:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 12:16:25 2024 Received: from localhost ([127.0.0.1]:40798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rt8iA-0001nc-3r for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 12:16:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rt8i6-0001aJ-06 for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 12:16:07 -0400 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 <eliz@HIDDEN>) 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==; Date: Sat, 06 Apr 2024 19:15:51 +0300 Message-Id: <86wmpa1n7s.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv4jceik0g.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 06 Apr 2024 11:46:28 -0400) Subject: Re: bug#70221: [PATCH] New function `funcall-later` References: <jwvbk6nh9c7.fsf@HIDDEN> <86zfu73smn.fsf@HIDDEN> <jwvy19qiozw.fsf-monnier+emacs@HIDDEN> <864jce34yv.fsf@HIDDEN> <jwv4jceik0g.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70221 Cc: 70221 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > From: Stefan Monnier <monnier@HIDDEN> > Cc: 70221 <at> 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.
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.
Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 15:46:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 11:46:51 2024
Received: from localhost ([127.0.0.1]:40649 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rt8Fn-0005FO-Gi
for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 11:46:51 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28552)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1rt8Fk-0005Ea-SR
for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 11:46:50 -0400
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==
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)
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)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#70221: [PATCH] New function `funcall-later`
In-Reply-To: <864jce34yv.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 06 Apr
2024 18:07:04 +0300")
Message-ID: <jwv4jceik0g.fsf-monnier+emacs@HIDDEN>
References: <jwvbk6nh9c7.fsf@HIDDEN> <86zfu73smn.fsf@HIDDEN>
<jwvy19qiozw.fsf-monnier+emacs@HIDDEN> <864jce34yv.fsf@HIDDEN>
Date: Sat, 06 Apr 2024 11:46:28 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.117 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 70221
Cc: 70221 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> 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
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.
Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 15:07:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 11:07:23 2024
Received: from localhost ([127.0.0.1]:40602 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rt7db-00024J-0X
for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 11:07:23 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:49436)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1rt7dX-00023V-DS
for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 11:07:21 -0400
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 <eliz@HIDDEN>)
id 1rt7dL-0002NZ-5H; Sat, 06 Apr 2024 11:07:07 -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=MpdwlovkcWz+gSREVDijjZWcs7lkcJVEhEAZI664f84=; b=g58y6U24mQba
udyejqf5KhbOBWRjiBcI5uxre61JDXdg5Swxdqu2Wk2bUhMlLhkiI+Q06rlQmrsNV8amc6AjmBT7M
wXeWb1dWV5/BbqlYtMeaIegZwKcQAejAPVF9/zh6k92zB6rcR7vG4EPL1yDTWUuQrTRNxr0hzs9cJ
uGANWn8sT146ELjH9PFN3TBD8FtsVwCt7O0Ao9+H7VuhlRtyJ8hJJVGzl+OVtGtQ4YBe5YvK1nbZ1
LECjiwRcg5jmvOhy0Mjjln6+D28NqY5pKfotMUg4bUdhsnYnj5CYVHnBaYATWqqYolSgbQis2gJ1a
CP3Jl6i6XXE+E9BFStnh+Q==;
Date: Sat, 06 Apr 2024 18:07:04 +0300
Message-Id: <864jce34yv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvy19qiozw.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Sat, 06 Apr 2024 10:33:05 -0400)
Subject: Re: bug#70221: [PATCH] New function `funcall-later`
References: <jwvbk6nh9c7.fsf@HIDDEN> <86zfu73smn.fsf@HIDDEN>
<jwvy19qiozw.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 70221
Cc: 70221 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 70221 <at> debbugs.gnu.org
> Date: Sat, 06 Apr 2024 10:33:05 -0400
>
> >> +DEFUN ("internal--run-pending-funcalls", Frun_pending_funcalls, Srun_pending_funcalls, 0, 0, 0,
> >> + doc: /* Run the still pending `funcall-later'. */)
> >> + (void)
> >> +{
> >> + while (CONSP (pending_funcalls) || CONSP (pending_funcalls_r))
> >> + if (CONSP (pending_funcalls))
> >> + {
> >> + Lisp_Object funcall = XCAR (pending_funcalls);
> >> + pending_funcalls = XCDR (pending_funcalls);
> >> + CALLN (Fapply, funcall);
> >> + }
> >> + else
> >
> > You are using CALLN here, whereas the previous implementation used
> > safe_calln. Is that intended? Calling Lisp in unsafe ways in that
> > place might not be a good idea.
>
> I found it annoying that the debugger isn't brought up when a bug
> occurs in such delayed evaluations. Note also the subsequent call to
> `timer-event-handler` uses `calln` rather than `safe_calln`, so I think
> my original use of `safe_call2` in commit 58555d8187f3425 was a mistake.
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.
> 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?
> > You didn't even inhibit QUIT.
>
> I'm torn on this one:
>
> OT1H while the time at which the code is run is loosely specified, it's
> not really asynchronous: it's run the next time Emacs "waits", which is
> usually about the same time as `post-command-hook` (which does use
> `inhibit-quit`), so there doesn't seem to be a good justification for
> `inhibit-quit`.
>
> OTOH when the `funcall-later` is performed from asynchronous code
> (e.g. from a timer), then running the delayed function call without
> `inhibit-quit` ends up "hoisting" that code outside of its original
> `inhibit-quit` context.
>
> For users such as `track-changes.el`, `inhibit-quit` is not
> needed/desired. But indeed when I use it in `futur.el` it's common to
> call `funcall-later` from process filters and timers.
>
> Usually part of the purpose of `funcall-later` is to run the code in
> a different (dynamic) context, but maybe `funcall-later` should
> preserve `inhibit-quit`?
From my POV, any code that runs from some background facility must
inhibit QUIT, because the user can type C-g at any moment.
> > As another difference between run-with-time and this mechanism, the
> > former took care of preserving deactivate-mark around the call, wheres
> > funcall-later doesn't
>
> This is again because `run-with-time` is designed for the general case
> where the delay is not 0s, so the code will be run asynchronously,
> wheres `funcall-later` is designed for "different time but not async".
I don't think it's a wise approach. 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.
> > -- this is at least one difference that we
> > should document (assuming we want 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?
> >> No: beside the fact that they are run at slightly different times
> >> (which might be OK), `funcall-later` doesn't return a handle you can
> >> then use to cancel the call.
> > This should be mentioned in the documentation.
>
> How/where?
In the same place, see above, where we compare those two features.
> Maybe the doc can just say that it returns nil?
> Other than that, it would seem odd to write something like
> "There is no `cancel-funcall-later`".
Not "out of the blue", but in the context of explaining how it is
different (which is important for Lisp programmers to decide which one
to use in what situations), it is reasonable.
> > Thanks. We should document this in the ELisp manual, and should
> > explain there the meaning of "at the next convenient time". (I think
> > "convenient" here is very much misleading and thus inappropriate.)
>
> 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:
>
> - `track-changes.el` uses `funcall-later` because it wants to delay the
> execution in order to combine the current buffer modification with
> potential soon-to-come buffer modifications.
> - `futur.el` uses `funcall-later` to "wake up" a piece of code that was
> waiting for the current event. In this case it uses `funcall-later`
> not because it wants to delay execution but because it wants that
> execution to be unaffected by the current dynamic scoping and it
> doesn't want that execution to block the current execution.
>
> So, if we were to change `funcall-later` so that the code gets run more
> promptly (e.g. via true concurrency [ let's pretend that this was
> actually possible and that the race-condition problems were magically
> solved somehow ]), it would be great for `futur.el` but would defeat the
> purpose for `track-changes.el`.
>
> Current users of `funcall-later` (well: of its underlying mechanism):
> - We use it in `comp.c` to launch the "jit" compilation of a package.
> - We use it in `frame.c` and `terminal.c` to run
> `(after-)delete-frame-functions` and `delete-terminal-functions` when
> the current context does not allow running ELisp.
>
> These are more like `futur.el` in the sense that the main purpose is
> to run the code in a different context, without blocking the
> current execution.
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".
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.
Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 14:33:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 10:33:25 2024
Received: from localhost ([127.0.0.1]:40550 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rt76j-0004gY-4T
for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 10:33:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62992)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1rt76e-0004gH-Gi
for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 10:33:23 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CC9A180C88;
Sat, 6 Apr 2024 10:33:07 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1712413986;
bh=Tf9qkDR88okm5en8tBQXr2tHGDNFn3qZ6GJOiOAkXAc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=h7gHLNl6rNdvBHOoNx5rkEUa4xCtGqbEHqeoYfo0lmJjduQXMpP2sHiCmSgnNmMlh
LtqWKszPjatcPqunftQ2Nt8wG1xyTsQdVxDAwXYgCJYAMtkVO84pLkFOI6PjkJi655
WZfLiNOTQsIimV7qy4c3ZyDkWfhh/pdhapjNrBtrwolU8LRLLhhw3PIdUmAxDw7xKx
lfsIuhprqSL2zhSK/hXzN8WSVML59xttowztpLT8uFGvoSGLW7szF9IFS2SgcDJg2X
SST5vVe6XutapWqCvPXgNAgFdshuPoq1Z0lVxcayN3gMl05fBrYaeiNyJChsKN4Kjy
h31dSIW5x3ykw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8C2DF8009D;
Sat, 6 Apr 2024 10:33:06 -0400 (EDT)
Received: from pastel (unknown [45.72.201.215])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 634EC120568;
Sat, 6 Apr 2024 10:33:06 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#70221: [PATCH] New function `funcall-later`
In-Reply-To: <86zfu73smn.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 06 Apr
2024 09:36:00 +0300")
Message-ID: <jwvy19qiozw.fsf-monnier+emacs@HIDDEN>
References: <jwvbk6nh9c7.fsf@HIDDEN> <86zfu73smn.fsf@HIDDEN>
Date: Sat, 06 Apr 2024 10:33:05 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.118 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 70221
Cc: 70221 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> +DEFUN ("internal--run-pending-funcalls", Frun_pending_funcalls, Srun_pending_funcalls, 0, 0, 0,
>> + doc: /* Run the still pending `funcall-later'. */)
>> + (void)
>> +{
>> + while (CONSP (pending_funcalls) || CONSP (pending_funcalls_r))
>> + if (CONSP (pending_funcalls))
>> + {
>> + Lisp_Object funcall = XCAR (pending_funcalls);
>> + pending_funcalls = XCDR (pending_funcalls);
>> + CALLN (Fapply, funcall);
>> + }
>> + else
>
> You are using CALLN here, whereas the previous implementation used
> safe_calln. Is that intended? Calling Lisp in unsafe ways in that
> place might not be a good idea.
I found it annoying that the debugger isn't brought up when a bug
occurs in such delayed evaluations. Note also the subsequent call to
`timer-event-handler` uses `calln` rather than `safe_calln`, so I think
my original use of `safe_call2` in commit 58555d8187f3425 was a mistake.
I can't see any good reason why we'd need to protect the
C code from non-local exits in `timer_check_2`.
> You didn't even inhibit QUIT.
I'm torn on this one:
OT1H while the time at which the code is run is loosely specified, it's
not really asynchronous: it's run the next time Emacs "waits", which is
usually about the same time as `post-command-hook` (which does use
`inhibit-quit`), so there doesn't seem to be a good justification for
`inhibit-quit`.
OTOH when the `funcall-later` is performed from asynchronous code
(e.g. from a timer), then running the delayed function call without
`inhibit-quit` ends up "hoisting" that code outside of its original
`inhibit-quit` context.
For users such as `track-changes.el`, `inhibit-quit` is not
needed/desired. But indeed when I use it in `futur.el` it's common to
call `funcall-later` from process filters and timers.
Usually part of the purpose of `funcall-later` is to run the code in
a different (dynamic) context, but maybe `funcall-later` should
preserve `inhibit-quit`?
> As another difference between run-with-time and this mechanism, the
> former took care of preserving deactivate-mark around the call, wheres
> funcall-later doesn't
This is again because `run-with-time` is designed for the general case
where the delay is not 0s, so the code will be run asynchronously,
wheres `funcall-later` is designed for "different time but not async".
> -- this is at least one difference that we
> should document (assuming we want 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.
>> No: beside the fact that they are run at slightly different times
>> (which might be OK), `funcall-later` doesn't return a handle you can
>> then use to cancel the call.
> This should be mentioned in the documentation.
How/where? Maybe the doc can just say that it returns nil?
Other than that, it would seem odd to write something like
"There is no `cancel-funcall-later`".
> Thanks. We should document this in the ELisp manual, and should
> explain there the meaning of "at the next convenient time". (I think
> "convenient" here is very much misleading and thus inappropriate.)
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:
- `track-changes.el` uses `funcall-later` because it wants to delay the
execution in order to combine the current buffer modification with
potential soon-to-come buffer modifications.
- `futur.el` uses `funcall-later` to "wake up" a piece of code that was
waiting for the current event. In this case it uses `funcall-later`
not because it wants to delay execution but because it wants that
execution to be unaffected by the current dynamic scoping and it
doesn't want that execution to block the current execution.
So, if we were to change `funcall-later` so that the code gets run more
promptly (e.g. via true concurrency [ let's pretend that this was
actually possible and that the race-condition problems were magically
solved somehow ]), it would be great for `futur.el` but would defeat the
purpose for `track-changes.el`.
Current users of `funcall-later` (well: of its underlying mechanism):
- We use it in `comp.c` to launch the "jit" compilation of a package.
- We use it in `frame.c` and `terminal.c` to run
`(after-)delete-frame-functions` and `delete-terminal-functions` when
the current context does not allow running ELisp.
These are more like `futur.el` in the sense that the main purpose is
to run the code in a different context, without blocking the
current execution.
Stefan
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 08:30:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 04:30:28 2024 Received: from localhost ([127.0.0.1]:38169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rt1RT-0004Vf-Sz for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 04:30:28 -0400 Received: from fout3-smtp.messagingengine.com ([103.168.172.146]:43235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1rt1RQ-0004UW-H3 for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 04:30:27 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfout.nyi.internal (Postfix) with ESMTP id 07A3313800A6; Sat, 6 Apr 2024 04:30:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 06 Apr 2024 04:30:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1712392213; x= 1712478613; bh=u/kRzhNQIE+Fdw3wHnRKczJOaKHaFGJgsG1QSUSMgGA=; b=N OZdhk5mN7PHxvjNnx/pU03nQLT5WYZCAua0Wf00mLhqwXUnfbkpAurzSk6DOzcs8 ZXahteHFTKRVuaW/6/xtP+o+K/ohtv/Nmf9oeJVnQjPFKJxMpP7CfDWaSjScPmGb R8zM9cZVoQ7X+x3sLyRu77VIlTULPah//9m7o+aoLRBTbzcG2kadegba7Nq1xlaI 8BfdUdkrsuqDM7YHQaiqypyyqmCuzNj/o243CNzMgR3Yi1eteaoztt10F+heSpCO QV6XS1Olt1Ii7pZywLDYs6smu7ZFCf6Mfbu0tdITM70QmqxPkJXOE1F7kwwofdx4 XKgg81k5ukUrQ9udmtArw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1712392213; x=1712478613; bh=u/kRzhNQIE+Fdw3wHnRKczJOaKHa FGJgsG1QSUSMgGA=; b=SPFpJ7oAdKjWJ7lPsft1kBTExR0NLbCPapii08KTYaeh n0cx4lV5nQSQfs9JTUS1QdslEhH0Qw3yuAj2yOnr+BSEvwegcDkw4GV32TIFn2w9 SuWJ6eHNHbVTU6z0QUDFMFTLgbzR6diXfkLZgkId2JXPCVVr7ARRiLZzB1b3xqG1 x7abX3YzoZgPz/Vl4RnJUdakzzM+LD2YL8+DZ9uIAHRHXsJUTZw3CVutQuCS3S3S daCqIzai+KtSdphThfa456CWPtLzguM9YV8Ph8sisOS83BLekZQvYMR1LmvGoFQL zGnJFfP9LJlykKxkp1wgPoi15E7oRfow9nKJIJ/ddg== X-ME-Sender: <xms:FAgRZjWNPUcmyn98v6QMga8b62nHcVbrFstTuISPr4zKC7u8DkHKog> <xme:FAgRZrnZ5AxRetPdnASzh0e7l_KPfDeaW-osEPhgtjwrWPg2S8WHHEgfjH7VZYWKb YCPbevBUk5WtecmEw> X-ME-Received: <xmr:FAgRZvZB-TSa_EA-ijn6i3bBa962s4liGK32AfxNinEo-rV3ZVzyg2PE7QWg2Q7ZwaTfkURVVAVCdg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudegvddgtdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefujghffffkfgggtgesthdttddttdertdenucfhrhhomhepufgvrghn ucghhhhithhtohhnuceoshhpfihhihhtthhonhesshhpfihhihhtthhonhdrnhgrmhgvqe enucggtffrrghtthgvrhhnpedtffdvffeuleeuvdetkedvveehgfehvdegvefghfevudek geegleevgeejkeetkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehsphifhhhithhtohhnsehsphifhhhithhtohhnrdhnrghmvg X-ME-Proxy: <xmx:FAgRZuWFD-cfWz1473LAUV5JSYjlaM1Dl85IpxZEi51_Tk66Ulk7Kw> <xmx:FAgRZtmER5VyjffAnHzCHncda-hN7zLZ0Z2FBbg1VdxoEEEzb_PbGQ> <xmx:FAgRZrciwfdoPlWFi8t76Hv_uqxsXQjuX-6fRN-vUzOEV8J6lDN5UA> <xmx:FAgRZnHDvSe2lu9n3L_enKIeLcEYvrJZAVf3vQbSBmLMS4pjE_D4DQ> <xmx:FQgRZjiIkHfJ6yNJGQRsXbCRpQ3ptoS617tH6j3hOBXAAWNWEf7_k2pH> Feedback-ID: i23c04076:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 6 Apr 2024 04:30:12 -0400 (EDT) Received: by melete.silentflame.com (Postfix, from userid 1000) id B8FE57E1D2C; Sat, 6 Apr 2024 16:30:09 +0800 (CST) From: Sean Whitton <spwhitton@HIDDEN> To: 70221 <at> debbugs.gnu.org Subject: Re: bug#70221: [PATCH] New function `funcall-later` In-Reply-To: <jwvbk6nh9c7.fsf@HIDDEN> (Stefan Monnier via's message of "Fri, 05 Apr 2024 15:56:40 -0400") References: <jwvbk6nh9c7.fsf@HIDDEN> Date: Sat, 06 Apr 2024 16:30:09 +0800 Message-ID: <87r0finbam.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 70221 Cc: Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Hello, On Fri 05 Apr 2024 at 03:56pm -04, Stefan Monnier wrote: > Tags: patch > > In the patch(es) below I suggest the addition of a new function > `funcall-later` which exposes the already existing `pending_funcalls` > mechanism to ELisp and fixes it so those are processed in the correct > order and so they're not just thrown away when used in batch mode. > > `run-with-timer` does largely the same thing when passed a 0 timeout > and no repetition, but it is a bit more costly and relies on the timers, > which don't work as well in batch mode. Very nice. You could also update xref--ensure-default-directory. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 08:14:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 04:14:54 2024 Received: from localhost ([127.0.0.1]:38150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rt1CQ-0000Uh-Lq for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 04:14:54 -0400 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:50400) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <felician.nemeth@HIDDEN>) id 1rt1CO-0000UD-4r for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 04:14:53 -0400 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-56e2ac1c16aso2180017a12.0 for <70221 <at> debbugs.gnu.org>; Sat, 06 Apr 2024 01:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712391280; x=1712996080; darn=debbugs.gnu.org; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=eIax8Yp1hvvWi7ytc8nQX5E4g4XlHFzyn9glLlHy5ow=; b=j4DLw+N5UCw+2CPRE9TFGDuYF8rVtTSVIr7it6ZDVPgEym6b/KEJuu10/XPTviKf6D zYc6Vcj4HT8c3J19e55oZCsvM/90rNitRHQRGG9wMc25i/4VeTlW17fSVVXw9Q+ceyep edrb9Hhy66XB1jT3iQ3F6wGkDgkassPC1Mifd1ut1uC2GpgbDzfQTQHF3iTF22fXNQuo rvfM8WeqFU6GhyU5oVjuGQE41vsMttrit83A8C6DMc7zpTabzlqku3F+dZ40Y4R4Clb0 487BMYQwU5V//WNcuWvlQ7oPP6fSJAcil/fEs4Fz+/rNlfPfEAczCtyyytBB+v3nRZFF pgUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712391280; x=1712996080; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eIax8Yp1hvvWi7ytc8nQX5E4g4XlHFzyn9glLlHy5ow=; b=GWkV6qLhswKy3Rs+GkLMyXkrwlyxMqs+833qCSjn4vgvOJMHVyK8+FDqHkmzOjzr9c CwgaeWq1HQPzHnitEFYyIB13PEXnox5MRNYgb/i8jJYIlCEG/sejLCctfMO/hIYZym22 N/mNb+rGSHXcvtEkDYp0hYTTHppsymzh9xIWiN/thYLBGpXoT4hcpbYQnIKuQRkCGkeI CylVdHZdsAfGe3Wbrc2ZpqYckavBFgw72+c+n6fbW/lhlTHFKakKVyWqYHV1W9fgPQu4 4Abjmz1ykto1E0b8BBCuBfHDABrRPX4oubX9MYCOAfHKnUMJpdimReMu61JdetrudItO 3W1Q== X-Forwarded-Encrypted: i=1; AJvYcCVpL6SwikV9LZXAaEs1uGd1uioZB46V6H3NJ+3IQm0Gq5u3Isq9xCeZuQv4/FAipwkOz6SlTVThb8/aiwvU5URrOnxVvnY= X-Gm-Message-State: AOJu0YxHgFYtjt3gCMOkiw6adCg8ylkkee3fH5iuPehE/ZS8ARKsP38U dGjpugjtDh9nVvgp4Tfr6/7fvkxNUU5Ttf8mc4Zmi6swQ5qZNYlT X-Google-Smtp-Source: AGHT+IFY+ilhbx/hk9mqO0lgXmC34iknH/vWXEFr/gH/M597kOca2NOIZIdkajzSNugeO/h1/0tzPQ== X-Received: by 2002:a50:8753:0:b0:566:777:af4f with SMTP id 19-20020a508753000000b005660777af4fmr2501299edv.1.1712391279804; Sat, 06 Apr 2024 01:14:39 -0700 (PDT) Received: from betli.gmail.com (catv-213-222-160-137.catv.fixed.vodafone.hu. [213.222.160.137]) by smtp.gmail.com with ESMTPSA id q22-20020a056402033600b0056c5d0c932bsm1666735edw.53.2024.04.06.01.14.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Apr 2024 01:14:39 -0700 (PDT) From: Felician Nemeth <felician.nemeth@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#70221: [PATCH] New function `funcall-later` References: <jwvbk6nh9c7.fsf@HIDDEN> <87v84vedqt.fsf@HIDDEN> <jwvr0fj8mbv.fsf-monnier+emacs@HIDDEN> <86v84v3rka.fsf@HIDDEN> Date: Sat, 06 Apr 2024 10:14:38 +0200 In-Reply-To: <86v84v3rka.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 06 Apr 2024 09:59:01 +0300") Message-ID: <87msq6ewlt.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEUMBwgHAgMFAAGPjY7/ //80MDHq6eqJt3pKAAABr0lEQVQ4jX2UzZKDIAzHqR177q7TPbtx2HMr6guQcrbY9txZ0fd/hA0f onXazcEJ/CD8E4Js8/HS9mwjXtqeMRxHXJkakTEm4b4GPVQW8PU8ov4fQCqeThlF60MBWdo1IXzd 2nEEZE7CEAZLwI0N/gJAhTj7ESQAX4gPgO8lyI+cvgViSVPlNomAj2M9gW40eg7VWY3cATjUcyiO Z+i03cFruGLYoUR7VyU3HihdmCEVhoDN65FXkpbSxkomOzsTQN/gySaodGb9Gdi1oSRXP46gdBWh LcUKJNdeGCWac74GKakmne0aHCFvyqJPYLsCFAVlhRTvGdzMdLHqtgRyUulyXIAH7CYQ3AB0Nody JQhAkq/qtOnbjhxdzYDkXPxlH5y4WdUAeUcX1NVJ6GR7UQEYPGWoAnA36OQNn5lRRp38vHTAp9Br LoTmvlPPDoRCKzpjG1SXT89AaT5l456BamJuMcs+NIOMzJ/s5dI6yUVcrARlruwOebfdv6gunTn4 ww3+QjGBEn5suVyLHoSGvAqREuDLN+iqZ+VcFg+HBbsJUU9+FZthbez9T+bdb+kPv2Ls6ct3hTkA AAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70221 Cc: 70221 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Compat Development <~pkal/compat-devel@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) >> Cc: 70221 <at> debbugs.gnu.org >> Date: Fri, 05 Apr 2024 18:44:05 -0400 >> From: Stefan Monnier via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> > Do this mean (run-with-timer 0 nil ...) can always be replaced with a >> > more efficient (funcall-later ...)? If so, would it make sense to >> > modify run-with-time as well to call funcall-later when if its first two >> > argument is (0 nil)? >> >> No: beside the fact that they are run at slightly different times >> (which might be OK), `funcall-later` doesn't return a handle you can >> then use to cancel the call. Does "running at slightly different times" mean that the compat package cannot reimplement funcall-later with run-with-time? Thanks again.
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 06:59:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 02:59:21 2024 Received: from localhost ([127.0.0.1]:38059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rt01I-00035W-99 for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 02:59:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rt01F-00034O-IY for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 02:59:18 -0400 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 <eliz@HIDDEN>) id 1rt013-0007VD-Dq; Sat, 06 Apr 2024 02:59:05 -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=hW7lgaAMhsda6SoQ/wEQEhGlY/q85dW6sS6Cz7gnw+s=; b=KbdNL2Ct19HX Ndh90E/5vqiTfvbBP8n0o8MTys3M3yzpH63qGziYyggrn/77gkqjofeL5unn7R/SWyJW01YMBtjgZ KFjMFcd2L6tz8+XyETI5bEk2ZxtP1VmOOTcY6vp6h3LmtgX/M2vsitaePwHGVTQ7+hyPdYzqLIU+K GFHCbmMlWHLQUcn5l8jztAd3eB5PgDVoEVoSgJnUNhOwtzpXhL288dV4QdnrybrlPprAm3avhw5kf EaQL4wDCh5raxdbVcbaYgeH1mSDVCOoRxohp749tc2akvs1G6oeRq5xgXJpR4ThjzKmJ5I2M6N5YW qMz8y1Rx4x52bcYvbMBB7g==; Date: Sat, 06 Apr 2024 09:59:01 +0300 Message-Id: <86v84v3rka.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvr0fj8mbv.fsf-monnier+emacs@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#70221: [PATCH] New function `funcall-later` References: <jwvbk6nh9c7.fsf@HIDDEN> <87v84vedqt.fsf@HIDDEN> <jwvr0fj8mbv.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70221 Cc: 70221 <at> debbugs.gnu.org, felician.nemeth@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 70221 <at> debbugs.gnu.org > Date: Fri, 05 Apr 2024 18:44:05 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > > Do this mean (run-with-timer 0 nil ...) can always be replaced with a > > more efficient (funcall-later ...)? If so, would it make sense to > > modify run-with-time as well to call funcall-later when if its first two > > argument is (0 nil)? > > No: beside the fact that they are run at slightly different times > (which might be OK), `funcall-later` doesn't return a handle you can > then use to cancel the call. This should be mentioned in the documentation.
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.
Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 06:36:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 02:36:20 2024
Received: from localhost ([127.0.0.1]:38010 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rszf0-0006uX-Ky
for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 02:36:20 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:60844)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1rszex-0006uH-7r
for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 02:36:17 -0400
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 <eliz@HIDDEN>)
id 1rszel-0007j9-2G; Sat, 06 Apr 2024 02:36:03 -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=YRORXZvNSBeXHqvrs76c6P1p2EApposiQDo0NmZQYP0=; b=jxST1smnfTxt
C271NwyHy3WWJLXK2MYxh3jqdUUJb0uxBko7n6QUtQPhm8WkXQ5iU1xDWSocC2VpP86MWyND6zbTw
01ixn2gPbWjU0nC93VVyG8+6m+EiEwWg4xkTeHYsLDSplH4xHJonerFsNU8Ya7ULl9E2i29qYg2Wk
XxDi+Q5F4UJx3byk+U9/FNZZu1t1J39BGq9zdInT4A8Z4m+uli+VbCmX8IdngaU8CeJ0XbVIBz5/m
NDvCFBUcKFStHw1/CtxJGQHMt9NFp8OWqm9QW1eZz628FNSni/OM0Ltiz0xaYgrOrXV7rHDyXUkN2
jqjP2HA538Nj1qYKy0vtIQ==;
Date: Sat, 06 Apr 2024 09:36:00 +0300
Message-Id: <86zfu73smn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvbk6nh9c7.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#70221: [PATCH] New function `funcall-later`
References: <jwvbk6nh9c7.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 70221
Cc: 70221 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Fri, 05 Apr 2024 15:56:40 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> +DEFUN ("internal--run-pending-funcalls", Frun_pending_funcalls, Srun_pending_funcalls, 0, 0, 0,
> + doc: /* Run the still pending `funcall-later'. */)
> + (void)
> +{
> + while (CONSP (pending_funcalls) || CONSP (pending_funcalls_r))
> + if (CONSP (pending_funcalls))
> + {
> + Lisp_Object funcall = XCAR (pending_funcalls);
> + pending_funcalls = XCDR (pending_funcalls);
> + CALLN (Fapply, funcall);
> + }
> + else
You are using CALLN here, whereas the previous implementation used
safe_calln. Is that intended? Calling Lisp in unsafe ways in that
place might not be a good idea. You didn't even inhibit QUIT.
As another difference between run-with-time and this mechanism, the
former took care of preserving deactivate-mark around the call, wheres
funcall-later doesn't -- this is at least one difference that we
should document (assuming we want it).
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.Received: (at 70221) by debbugs.gnu.org; 6 Apr 2024 06:09:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 02:09:43 2024 Received: from localhost ([127.0.0.1]:37967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rszFH-00026z-3t for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 02:09:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rszFE-000269-HQ for 70221 <at> debbugs.gnu.org; Sat, 06 Apr 2024 02:09:41 -0400 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 <eliz@HIDDEN>) id 1rszF3-0006yW-4J; Sat, 06 Apr 2024 02:09:29 -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=u8bnQubwoWUZQriMiK5f52AklUsm7JDj+AygGlIxDRw=; b=fwdRMPoeVOG1 fqiDNeNOlbIAJejT3xMTCx2Ng261l2QMK0eKo8BM7J7pLqBfYhtKuF7EpOWyCaTUec7c6ZcCPdZ+d BAWDpYH67OWQjRyaSifIGCjtVr1gfL7Gal6kjeKRK7rG8fHi/GAcBwFTH6Itsk6vQf8npo66KuFwN hhuzzMJ72kv47R1GHTKH0Ntqf/qMxGqdJk4nM1MecHHxsyxiLvIqbo4wAp0urpscRbZs//1cGoi/M IO/Vivg68tatASHaUn1QX+8aj0EgNKsJc19u7HkrHH72sgd6wtnWCMb0/0/xHsbzkdIdI+e3yXXmF 9ZlJY6UCSPM2XQ7n3s7b9A==; Date: Sat, 06 Apr 2024 09:09:25 +0300 Message-Id: <8634rz58fe.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvbk6nh9c7.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#70221: [PATCH] New function `funcall-later` References: <jwvbk6nh9c7.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70221 Cc: 70221 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 05 Apr 2024 15:56:40 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > In the patch(es) below I suggest the addition of a new function > `funcall-later` which exposes the already existing `pending_funcalls` > mechanism to ELisp and fixes it so those are processed in the correct > order and so they're not just thrown away when used in batch mode. > > `run-with-timer` does largely the same thing when passed a 0 timeout > and no repetition, but it is a bit more costly and relies on the timers, > which don't work as well in batch mode. Thanks. We should document this in the ELisp manual, and should explain there the meaning of "at the next convenient time". (I think "convenient" here is very much misleading and thus inappropriate.)
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.
Received: (at 70221) by debbugs.gnu.org; 5 Apr 2024 22:46:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 05 18:46:56 2024
Received: from localhost ([127.0.0.1]:37712 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rssKk-0006ty-Je
for submit <at> debbugs.gnu.org; Fri, 05 Apr 2024 18:46:55 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41773)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1rssKh-0006tE-FC
for 70221 <at> debbugs.gnu.org; Fri, 05 Apr 2024 18:46:52 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 36C91441474;
Fri, 5 Apr 2024 18:46:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1712357198;
bh=hSHgTy54NlhH/VvcmHSeXWEPLb2ubkVoIYo8Hd3UpKM=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=KbDHNNqNY6kAwu3jOy5oEzEqgAyMfsUcTtF/HiWVGwXzdNFnuYITIGF1AZVOOinRP
l+l1bmRiVaEpyM/VK45Ofri11rgvJFxQXOLenbNMSjM9P1HgDkjpo5FWv172ywJWK/
3EmotrpyPRXvFDePbn90D3eLuB59RZPNad1cAXoUNssdYGeKO7UTN79rASMvfu/PfU
CDO8volHIy9oqRFcNxRkBl92l6z5iuLxlQRDYxBkX+1qQ9GvzKsGJt1nRXuBuJCX+U
UXdQO0F/Yq09rvHVFarzUJKxKxK/srkTEGfNF0ewmc6EiIWlShxh7ml6HSUe2BWTg/
5toQdBE1ADOWw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0FB444413B4;
Fri, 5 Apr 2024 18:46:38 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F173512032D;
Fri, 5 Apr 2024 18:46:37 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Felician Nemeth <felician.nemeth@HIDDEN>
Subject: Re: bug#70221: [PATCH] New function `funcall-later`
In-Reply-To: <87v84vedqt.fsf@HIDDEN> (Felician Nemeth's message of
"Fri, 05 Apr 2024 22:49:46 +0200")
Message-ID: <jwvr0fj8mbv.fsf-monnier+emacs@HIDDEN>
References: <jwvbk6nh9c7.fsf@HIDDEN>
<87v84vedqt.fsf@HIDDEN>
Date: Fri, 05 Apr 2024 18:44:05 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.030 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 70221
Cc: 70221 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Do this mean (run-with-timer 0 nil ...) can always be replaced with a
> more efficient (funcall-later ...)? If so, would it make sense to
> modify run-with-time as well to call funcall-later when if its first two
> argument is (0 nil)?
No: beside the fact that they are run at slightly different times
(which might be OK), `funcall-later` doesn't return a handle you can
then use to cancel the call.
Stefan
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.Received: (at 70221) by debbugs.gnu.org; 5 Apr 2024 20:50:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 05 16:50:07 2024 Received: from localhost ([127.0.0.1]:37632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rsqVi-0007Mt-Uh for submit <at> debbugs.gnu.org; Fri, 05 Apr 2024 16:50:07 -0400 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]:61524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <felician.nemeth@HIDDEN>) id 1rsqVc-0007La-AQ for 70221 <at> debbugs.gnu.org; Fri, 05 Apr 2024 16:50:04 -0400 Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a51b5633c9cso14602766b.2 for <70221 <at> debbugs.gnu.org>; Fri, 05 Apr 2024 13:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712350188; x=1712954988; darn=debbugs.gnu.org; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=5v8dl/H0KLCHWEnEi2Zq9A4wt8BVnDecnvZ9wa4iZwk=; b=IJYr4hIqGOpb43RxwvzRoHrNFmzpvKWykhIJeu3TfvZAbOUpiKJl0OFQVId4h0DqXB YYTCArDQjBgn1sz3heR0tGQtSXTB0hTOb6vC6S4yz3u0JxPGMufGgQfzC/wauq1PsiDA PtMjZy8YjDlDc6xIw7cW1+Ds0n7TcVVQY1KIMS4S0/81js5SXAHGdY1AgQf/HF857BRw 9hze4N6uCQBHUxEWp5jd3etIicNXKWicZ7xTtkxsdaWfsid0QUR6tALbqo/JawElVeKE aYDQtmWJgjKYQO3JaD6fqSYplwHdDV59JAfIosCIwHFweRmBDDwZra166pQybVmWzhPF XnLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712350188; x=1712954988; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5v8dl/H0KLCHWEnEi2Zq9A4wt8BVnDecnvZ9wa4iZwk=; b=Ht341c3RtkI9dvADKoQbSqDjYfN/lW0rX2TB8R1Dx+DRj0WWm6c+dLS0+jA2NegthT iGGB8hmh6QDyKsq1ztmhZVJzvfhWnno/fW9NwOreU1E8nnv5xSnCj0rHX0yNHfQ9WmvC hjHPfnUGGMZzExfCMiM6R+bd876Ac/aHXuaDuOpfgk2nt/DgEIWClB6dVZH3HLSzhY7F /OTFzSyDRai6QvQLlQCniQTADNqX1b5QK9guQrhOSlIW9jf270Tie1U58Qr3/ze3gXqj ys0FVgvxI1+P3tqJ6VtHPS07+2G5b6CAp97Y2szPU+cwW4giG12KyYTEUJVDdF0ae2Gt KArw== X-Gm-Message-State: AOJu0YyaR8JsP7ZEvjfyvI6b7Qz3uF71YvKjAP4dYEwiQvq/4hfAWrgQ xdMkNvwF0jFI22C9ms7NLEI88sqBX3FJXXuYj77HVj9fMMUo/dQaVFKIWLXQ X-Google-Smtp-Source: AGHT+IFu5oJC68+HXQ98woF46goB38LJvuGFUjjq67Kdi738p5dzv9tjELoyJRVgi8oGxcVRmzPsLQ== X-Received: by 2002:a17:906:81ca:b0:a47:2087:c26f with SMTP id e10-20020a17090681ca00b00a472087c26fmr1546612ejx.73.1712350187436; Fri, 05 Apr 2024 13:49:47 -0700 (PDT) Received: from betli.gmail.com (catv-213-222-160-137.catv.fixed.vodafone.hu. [213.222.160.137]) by smtp.gmail.com with ESMTPSA id e3-20020a170906844300b00a4e5ab88803sm1223239ejy.183.2024.04.05.13.49.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Apr 2024 13:49:47 -0700 (PDT) From: Felician Nemeth <felician.nemeth@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#70221: [PATCH] New function `funcall-later` References: <jwvbk6nh9c7.fsf@HIDDEN> Date: Fri, 05 Apr 2024 22:49:46 +0200 In-Reply-To: <jwvbk6nh9c7.fsf@HIDDEN> (Stefan Monnier via's message of "Fri, 05 Apr 2024 15:56:40 -0400") Message-ID: <87v84vedqt.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEU2EgDVmFNHKAa4dz4q AwCDUSH2zWrE61tmAAACeklEQVQ4jU2UwY7jIAyGEZN5ABSFc9Ytcx6K6DmqmHsD8tyZKrz/I+xv yI6WKlHlj982tomiVckiWrUrgRU5jlqMpJKCkch5W419DQAiQGHDxdrWmm0/2kXCApiUmrZLq20s cjexq3VL25QuxjY7wOcJVEpb+jLeGLAK+OMyaa1hx9rFbkwHFWBVA2y8w1wHaLE7GuDdw5cEuOM5 SLIdrpwBkN0ezwI7nYoiilqthbcYc89KgC5+NnaOHGbZz0T6BCEgOLJ0vmYXuNdPAIXgDZJhF2Yu fjnPNwAsoUTUN/P8q3AAyz4zB/xmifEfiIbvS4jh7b7QqZiSm4MJC5kXNpCRaOsoyQXAMN2XCJfs j94NKfo7ACKUEgKE3y+Sg4jibUZ1A0jgYpxtvYMC3gHaHPq6x32ACeALIZoZxB+l9VrRNIA1ncRg wwC8pvQIvYO+a2yt3VXMVyli6L0VV6aOrJa4CpilVQA+eHt0xavk61akih5BUMay/0BAqu783C5h FifY/3QsAIoWYk6PgpwAzLI652+96e2IfN2cF+BD1uT23F21Ghh5OUl4RlO15oh5A2iv+Zk2wsjZ 2DtB5Sm3A4P0+kyb2vs4iEW7G9ohoN3Stl2kVat6MCkXldo6OKaE8P6GhmrKKxWZXQH1iklhhn+d iVeNf6mDdkV0ltFwApRbp+kXSGBFHGV2aPqnIIyQyzhD5n47khqKI08bIapcas4O+hPkct20NAEv ALRuZFUp3PrnQSAm+4lTdHCsYYZ/nGqQrM5z3NS3zefFxkfFPRFbsjpIfbTlvF3ibpVZQ9nzqv60 F/KXSRLJ1AGappJulZll70N/qz6EfwEOCdYOuTHAzAAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70221 Cc: 70221 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > `run-with-timer` does largely the same thing when passed a 0 timeout > and no repetition, but it is a bit more costly and relies on the timers, > which don't work as well in batch mode. Do this mean (run-with-timer 0 nil ...) can always be replaced with a more efficient (funcall-later ...)? If so, would it make sense to modify run-with-time as well to call funcall-later when if its first two argument is (0 nil)? Thanks.
bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 5 Apr 2024 19:59:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Apr 05 15:59:54 2024
Received: from localhost ([127.0.0.1]:37538 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rspj6-0003ao-3q
for submit <at> debbugs.gnu.org; Fri, 05 Apr 2024 15:59:54 -0400
Received: from lists.gnu.org ([2001:470:142::17]:55600)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1rspj3-0003Zw-24
for submit <at> debbugs.gnu.org; Fri, 05 Apr 2024 15:59:50 -0400
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 <monnier@HIDDEN>)
id 1rspir-0006uG-Js
for bug-gnu-emacs@HIDDEN; Fri, 05 Apr 2024 15:59:37 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <monnier@HIDDEN>)
id 1rspio-0001Ot-SH
for bug-gnu-emacs@HIDDEN; Fri, 05 Apr 2024 15:59:37 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5D76A80C41
for <bug-gnu-emacs@HIDDEN>; Fri, 5 Apr 2024 15:59:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1712347170;
bh=UqfkEngsOSumEQTMBGp3gsRNzj0p3/2RHUDIExdn7/U=;
h=From:To:Subject:Date:From;
b=oOs/Bqg98e05LDW2hjSTH9+DqQLo6oE53IfOi5RY2CI+840QKDD8r0ezd2lpEWAJv
COhkdEaS3oq9dKTfmjjSk2tx4kPr5fD/lyuIkl3GmDwE2RjZoJ9ficCM0YDvRvrrA7
wvpuIbWin/HL2RudumsSEwMAEC8YvZ+z0G31eD2raOtSxGrSEJqVTZ8QM82WGVYO/i
JilBrHfGnhl+GQs8/I1+1Q947hHJZYEWsKPWjPzNeRG3YByaLQCHc6dI4ZGsGtiB+4
RHu8uKopOvBFRdXQOdc1PLhakoTsFchB7RYUwk0iKyv4rXNw+iRDMm7Wu8Uy1v/4kE
KHBb12gIXrDpA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7848D8009D
for <bug-gnu-emacs@HIDDEN>; Fri, 5 Apr 2024 15:59:30 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6B321120193
for <bug-gnu-emacs@HIDDEN>; Fri, 5 Apr 2024 15:59:30 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] New function `funcall-later`
Date: Fri, 05 Apr 2024 15:56:40 -0400
Message-ID: <jwvbk6nh9c7.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.161 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
Received-SPF: pass client-ip=132.204.25.50;
envelope-from=monnier@HIDDEN; 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-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
Tags: patch
In the patch(es) below I suggest the addition of a new function
`funcall-later` which exposes the already existing `pending_funcalls`
mechanism to ELisp and fixes it so those are processed in the correct
order and so they're not just thrown away when used in batch mode.
`run-with-timer` does largely the same thing when passed a 0 timeout
and no repetition, but it is a bit more costly and relies on the timers,
which don't work as well in batch mode.
Stefan
In GNU Emacs 30.0.50 (build 1, i686-pc-linux-gnu, GTK+ Version 3.24.41,
cairo version 1.18.0) of 2024-03-27 built on lechazo
Repository revision: a13cfe9bb17448e104dc86b7a33761ca60297871
Repository branch: work
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Debian GNU/Linux trixie/sid
Configured using:
'configure -C --enable-checking --enable-check-lisp-object-type --with-modules --with-cairo --with-tiff=ifavailable
'CFLAGS=-Wall -g3 -Og -Wno-pointer-sign' --without-native-compilation
PKG_CONFIG_PATH=/home/monnier/lib/pkgconfig'
--=-=-=
Content-Type: text/patch
Content-Disposition: attachment;
filename=0001-Ffuncall_later-New-function-to-expose-pending_funcal.patch
From 0041d6272d91baceada67aec04a0bca66a64919b Mon Sep 17 00:00:00 2001
From: Stefan Monnier <monnier@HIDDEN>
Date: Fri, 5 Apr 2024 14:58:53 -0400
Subject: [PATCH 1/2] (Ffuncall_later): New function to expose
'pending_funcalls' to ELisp
* src/keyboard.c (pending_funcalls): Make static.
(pending_funcalls_r): New var.
(Ffuncall_later): New Lisp function.
(Frun_pending_funcalls): New function, extracted from 'timer_check_2'.
Improve the code to preserve the order in which functions were added.
(timer_check_2): Use it.
(syms_of_keyboard): Initialize and staticpro 'pending_funcalls_r',
and defsubr 'Sfuncall_later' and 'Srun_pending_funcalls'.
(syms_of_keyboard_for_pdumper): Reset 'pending_funcalls_r'.
* lisp/startup.el (command-line): Run pending funcalls before exiting,
in batch mode.
* src/lisp.h (pending_funcalls): Remove declaration.
* src/frame.c (delete_frame):
* src/terminal.c (Fdelete_terminal):
* src/comp.c (maybe_defer_native_compilation): Use 'Ffuncall_later'.
---
etc/NEWS | 4 ++++
lisp/startup.el | 2 +-
src/comp.c | 4 +---
src/frame.c | 10 ++++------
src/keyboard.c | 47 +++++++++++++++++++++++++++++++++++++----------
src/lisp.h | 1 -
src/terminal.c | 6 ++----
7 files changed, 49 insertions(+), 25 deletions(-)
diff --git a/etc/NEWS b/etc/NEWS
index 32cec82f970..8e8cbcdeb5d 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1761,6 +1761,10 @@ correctly UTF-8 encoded.
* Lisp Changes in Emacs 30.1
+** New function 'funcall-later', to run code at the next convenient time.
+This is very similar to 'run-with-timer' with a 0 time argument, but cheaper
+and it also works in batch mode.
+
** New function 'help-fns-function-name'.
For named functions, it just returns the name and otherwise
it returns a short "unique" string that identifies the function.
diff --git a/lisp/startup.el b/lisp/startup.el
index 357a4154e4c..c105886908c 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1630,7 +1630,7 @@ command-line
:warning))))
;; If -batch, terminate after processing the command options.
- (if noninteractive (kill-emacs t))
+ (when noninteractive (internal--run-pending-funcalls) (kill-emacs t))
;; In daemon mode, start the server to allow clients to connect.
;; This is done after loading the user's init file and after
diff --git a/src/comp.c b/src/comp.c
index 99f51e07048..f59881a1b84 100644
--- a/src/comp.c
+++ b/src/comp.c
@@ -5217,9 +5217,7 @@ maybe_defer_native_compilation (Lisp_Object function_name,
Fputhash (function_name, definition, Vcomp_deferred_pending_h);
- pending_funcalls
- = Fcons (list (Qnative__compile_async, src, Qnil, Qlate),
- pending_funcalls);
+ CALLN (Ffuncall_later, Qnative__compile_async, src, Qnil, Qlate);
}
diff --git a/src/frame.c b/src/frame.c
index abd6ef00901..f2ed55046d6 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -2138,9 +2138,8 @@ delete_frame (Lisp_Object frame, Lisp_Object force)
if (NILP (Vrun_hooks) || is_tooltip_frame)
;
else if (EQ (force, Qnoelisp))
- pending_funcalls
- = Fcons (list3 (Qrun_hook_with_args, Qdelete_frame_functions, frame),
- pending_funcalls);
+ CALLN (Ffuncall_later, Qrun_hook_with_args,
+ Qdelete_frame_functions, frame);
else
{
#ifdef HAVE_X_WINDOWS
@@ -2456,9 +2455,8 @@ delete_frame (Lisp_Object frame, Lisp_Object force)
if (NILP (Vrun_hooks) || is_tooltip_frame)
;
else if (EQ (force, Qnoelisp))
- pending_funcalls
- = Fcons (list3 (Qrun_hook_with_args, Qafter_delete_frame_functions, frame),
- pending_funcalls);
+ CALLN (Ffuncall_later, Qrun_hook_with_args,
+ Qafter_delete_frame_functions, frame);
else
safe_calln (Qrun_hook_with_args, Qafter_delete_frame_functions, frame);
diff --git a/src/keyboard.c b/src/keyboard.c
index 91faf4582fa..45f7295d5d1 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -4624,10 +4624,38 @@ timer_resume_idle (void)
timer_idleness_start_time = timer_last_idleness_start_time;
}
-/* List of elisp functions to call, delayed because they were generated in
- a context where Elisp could not be safely run (e.g. redisplay, signal,
+/* List of elisp functions to call, delayed e.g. because they were generated in
+ a context where that code could not be safely run (e.g. redisplay, signal,
...). Each element has the form (FUN . ARGS). */
-Lisp_Object pending_funcalls;
+static Lisp_Object pending_funcalls, pending_funcalls_r;
+
+DEFUN ("funcall-later", Ffuncall_later, Sfuncall_later, 1, MANY, 0,
+ doc: /* Schedule FUNCTION for later execution.
+It will be called a soon as possible with ARGS, but not now. */)
+ (ptrdiff_t nargs, Lisp_Object *args)
+{
+ pending_funcalls_r = Fcons (Flist (nargs, args), pending_funcalls_r);
+ return Qnil;
+}
+
+DEFUN ("internal--run-pending-funcalls", Frun_pending_funcalls, Srun_pending_funcalls, 0, 0, 0,
+ doc: /* Run the still pending `funcall-later'. */)
+ (void)
+{
+ while (CONSP (pending_funcalls) || CONSP (pending_funcalls_r))
+ if (CONSP (pending_funcalls))
+ {
+ Lisp_Object funcall = XCAR (pending_funcalls);
+ pending_funcalls = XCDR (pending_funcalls);
+ CALLN (Fapply, funcall);
+ }
+ else
+ {
+ pending_funcalls = Fnreverse (pending_funcalls_r);
+ pending_funcalls_r = Qnil;
+ }
+ return Qnil;
+}
/* Return true if TIMER is a valid timer, placing its value into *RESULT. */
static bool
@@ -4671,12 +4699,7 @@ timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers)
chosen_timer = Qnil;
/* First run the code that was delayed. */
- while (CONSP (pending_funcalls))
- {
- Lisp_Object funcall = XCAR (pending_funcalls);
- pending_funcalls = XCDR (pending_funcalls);
- safe_calln (Qapply, XCAR (funcall), XCDR (funcall));
- }
+ Frun_pending_funcalls ();
if (CONSP (timers) || CONSP (idle_timers))
{
@@ -12783,8 +12806,9 @@ is_ignored_event (union buffered_input_event *event)
void
syms_of_keyboard (void)
{
- pending_funcalls = Qnil;
+ pending_funcalls = pending_funcalls_r = Qnil;
staticpro (&pending_funcalls);
+ staticpro (&pending_funcalls_r);
Vlispy_mouse_stem = build_pure_c_string ("mouse");
staticpro (&Vlispy_mouse_stem);
@@ -13084,6 +13108,8 @@ syms_of_keyboard (void)
defsubr (&Scurrent_idle_time);
defsubr (&Sevent_symbol_parse_modifiers);
defsubr (&Sevent_convert_list);
+ defsubr (&Sfuncall_later);
+ defsubr (&Srun_pending_funcalls);
defsubr (&Sinternal_handle_focus_in);
defsubr (&Sread_key_sequence);
defsubr (&Sread_key_sequence_vector);
@@ -13855,6 +13881,7 @@ syms_of_keyboard_for_pdumper (void)
early init functions see the environment they expect. */
PDUMPER_RESET_LV (pending_funcalls, Qnil);
+ PDUMPER_RESET_LV (pending_funcalls_r, Qnil);
PDUMPER_RESET_LV (unread_switch_frame, Qnil);
PDUMPER_RESET_LV (internal_last_event_frame, Qnil);
PDUMPER_RESET_LV (last_command_event, Qnil);
diff --git a/src/lisp.h b/src/lisp.h
index 3cb4361e75e..d9308cbc6dd 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -5106,7 +5106,6 @@ fast_c_string_match_ignore_case (Lisp_Object regexp,
#if defined (USABLE_SIGIO) || defined (USABLE_SIGPOLL)
void handle_input_available_signal (int);
#endif
-extern Lisp_Object pending_funcalls;
extern bool detect_input_pending (void);
extern bool detect_input_pending_ignore_squeezables (void);
extern bool detect_input_pending_run_timers (bool);
diff --git a/src/terminal.c b/src/terminal.c
index 23a5582d4d9..fd13ba90792 100644
--- a/src/terminal.c
+++ b/src/terminal.c
@@ -384,10 +384,8 @@ DEFUN ("delete-terminal", Fdelete_terminal, Sdelete_terminal, 0, 2, 0,
if (NILP (Vrun_hooks))
;
else if (EQ (force, Qnoelisp))
- pending_funcalls
- = Fcons (list3 (Qrun_hook_with_args,
- Qdelete_terminal_functions, terminal),
- pending_funcalls);
+ CALLN (Ffuncall_later, Qrun_hook_with_args,
+ Qdelete_terminal_functions, terminal);
else
safe_calln (Qrun_hook_with_args, Qdelete_terminal_functions, terminal);
--
2.43.0
--=-=-=
Content-Type: text/patch
Content-Disposition: inline;
filename=0002-lisp-Prefer-funcall-later-over-run-with-timer.patch
From 24d444a272bd4b42739a1883c4d5f0545dfce58a Mon Sep 17 00:00:00 2001
From: Stefan Monnier <monnier@HIDDEN>
Date: Fri, 5 Apr 2024 15:49:34 -0400
Subject: [PATCH 2/2] lisp: Prefer 'funcall-later' over 'run-with-timer'
* lisp/subr.el (do-after-load-evaluation):
* lisp/server.el (server-goto-toplevel):
* lisp/progmodes/compile.el (compilation-error-properties):
* lisp/menu-bar.el (menu-bar-mode):
* lisp/jit-lock.el (jit-lock-fontify-now):
* lisp/emacs-lisp/edebug.el (edebug-kill-buffer)
(edebug-unload-function): Use 'funcall-later' i.s.o 'run-with-timer'.
---
lisp/emacs-lisp/edebug.el | 4 ++--
lisp/jit-lock.el | 6 +++---
lisp/menu-bar.el | 6 +++---
lisp/progmodes/compile.el | 4 ++--
lisp/server.el | 2 +-
lisp/subr.el | 3 +--
6 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index b27ffbca908..fc76552312f 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -4023,7 +4023,7 @@ edebug-mode
(defun edebug-kill-buffer ()
"Used on `kill-buffer-hook' when Edebug is operating in a buffer of Lisp code."
- (run-with-timer 0 nil #'top-level))
+ (funcall-later #'top-level))
;;; edebug eval list mode
@@ -4597,7 +4597,7 @@ edebug-unload-function
(unwind-protect
(abort-recursive-edit)
;; We still want to run unload-feature to completion
- (run-with-idle-timer 0 nil #'(lambda () (unload-feature 'edebug)))))
+ (funcall-later #'unload-feature 'edebug)))
(remove-hook 'called-interactively-p-functions
#'edebug--called-interactively-skip)
(edebug-uninstall-read-eval-functions)
diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
index 05c0bd847b3..14c172c1e6a 100644
--- a/lisp/jit-lock.el
+++ b/lisp/jit-lock.el
@@ -478,9 +478,9 @@ jit-lock-fontify-now
;; eagerly extend the refontified region with
;; jit-lock-after-change-extend-region-functions.
(when (< loose-beg orig-start)
- (run-with-timer 0 nil #'jit-lock-force-redisplay
- (copy-marker loose-beg)
- (copy-marker orig-start)))
+ (funcall-later #'jit-lock-force-redisplay
+ (copy-marker loose-beg)
+ (copy-marker orig-start)))
;; Skip to the end of the fully refontified part.
(setq start tight-end)))
diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index 320fabb54cf..7a4de133b74 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -2632,9 +2632,9 @@ menu-bar-mode
;; directly. The minor-mode message "Menu Bar mode disabled" comes
;; after this function returns, overwriting any message we do here.
(when (and (called-interactively-p 'interactive) (not menu-bar-mode))
- (run-with-idle-timer 0 nil 'message
- (substitute-command-keys
- "Menu Bar mode disabled. \
+ (funcall-later #'message
+ (substitute-command-keys
+ "Menu Bar mode disabled. \
Use \\[menu-bar-mode] to make the menu bar appear."))))
;;;###autoload
diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 11d400e145a..952f03d3155 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1402,8 +1402,8 @@ compilation-error-properties
(when (and compilation-auto-jump-to-next
(>= type compilation-skip-threshold))
(kill-local-variable 'compilation-auto-jump-to-next)
- (run-with-timer 0 nil 'compilation-auto-jump
- (current-buffer) (match-beginning 0)))
+ (funcall-later #'compilation-auto-jump
+ (current-buffer) (match-beginning 0)))
(compilation-internal-error-properties
file line end-line col end-col type fmt rule))))
diff --git a/lisp/server.el b/lisp/server.el
index b65053267a6..8e3c1d0a467 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -1031,7 +1031,7 @@ server-goto-toplevel
;; to open a frame on a new display, we might end up with an unusable
;; frame because input from that display will be blocked (until exiting
;; the minibuffer). Better exit this minibuffer right away.
- (run-with-timer 0 nil (lambda () (server-execute-continuation proc)))
+ (funcall-later #'server-execute-continuation proc)
(top-level)))
;; We use various special properties on process objects:
diff --git a/lisp/subr.el b/lisp/subr.el
index fba70342154..20fdf8deded 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -5981,8 +5981,7 @@ do-after-load-evaluation
byte-compile-current-file
byte-compile-root-dir)))
(byte-compile-warn "%s" msg)))
- (noninteractive (funcall fun msg)) ;; No timer will be run!
- (t (run-with-idle-timer 0 nil fun msg))))))
+ (t (funcall-later fun msg))))))
;; Finally, run any other hook.
(run-hook-with-args 'after-load-functions abs-file))
--
2.43.0
--=-=-=--
Stefan Monnier <monnier@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#70221; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.