GNU bug report logs - #70221
[PATCH] New function `funcall-later`

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Stefan Monnier <monnier@HIDDEN>; Keywords: patch; dated Fri, 5 Apr 2024 20:00:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 70221 <at> debbugs.gnu.org:


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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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".




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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.)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at 70221 <at> debbugs.gnu.org:


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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


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


--=-=-=--





Acknowledgement sent to Stefan Monnier <monnier@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#70221; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sat, 6 Apr 2024 16:30:03 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.