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.