Received: (at 80468) by debbugs.gnu.org; 25 Feb 2026 12:29:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 25 07:29:19 2026 Received: from localhost ([127.0.0.1]:55827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vvE11-0000F1-Ad for submit <at> debbugs.gnu.org; Wed, 25 Feb 2026 07:29:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39716) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vvE0x-0000EE-Tc for 80468 <at> debbugs.gnu.org; Wed, 25 Feb 2026 07:29:16 -0500 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 1vvE0r-0007NH-6T; Wed, 25 Feb 2026 07:29:09 -0500 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=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=VFhfGxJl7wJ+ W1w+allXpLtLRDFdzoMHc+61TnTZloOOlWsuwQ2KB9HAWziekXzE4ACZ98mSIAwlGOzxRjwAFLVQz SmGgWdajX9yuF/U5whVz+R4NbuPJwXF1Hm/vSE/biYgB+aruC7i03EZlbo6AJ9Y5nu6HoiTrIPuA/ wYJjS38rmMdl+g112F19XfU6sShPDFAsjwNxC9Z72OTuTtOlo/s9UOgaHS9esQvqAnMg74QC14IpA nMTbcZX9G8l0PzbgPxoL0ENpZWgFQFLDOy6DhaLi9wqY7br9m/sUlm1vM/70ZO73NjZMnF9y7q6Rm cOzN54gqm6WVJBUvoQBsAw==; Date: Wed, 25 Feb 2026 14:29:06 +0200 Message-Id: <86ms0x80rx.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv5x7ldh6r.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 24 Feb 2026 15:31:30 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> <jwvzf4z3w86.fsf-monnier+emacs@HIDDEN> <86v7fm9p4f.fsf@HIDDEN> <jwvecmadle1.fsf-monnier+emacs@HIDDEN> <86o6ld99ov.fsf@HIDDEN> <jwv5x7ldh6r.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, dancol@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 (---)
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 20:31:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 15:31:50 2026 Received: from localhost ([127.0.0.1]:46567 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuz4O-0000l2-37 for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 15:31:49 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1684) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vuz4K-0000jb-6u for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 15:31:46 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E279780966; Tue, 24 Feb 2026 15:31:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1771965091; bh=huvQWDfhgkgr2TaPKzcvFwHF9w5o0R7vjeWk/bne5lg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XNZN/tjLZRSRxD4JWfKru+cV0yGDzzDHseYNFzWTf9tUHp5oRhv0k7LY9IeS7W4yB J3DxqNmeIVC3wgt9mZrOEeRsUpefstyfkhqI5UOABvjNZvJ9mFVupxvB43Z5/whooA ska0XpBVawjEh1cMe5bkLyrCxZeTwst49PuZQJpGg+FBvQmwXqyxNA7eX0lJb9ziT8 MUVMelq0Ysvq0+KyL3zr+geBNsHCxgEIUd5AQGDfMoGrw23hDkU03kd7u5SVvYiWSl +X8XM20u/VMud6pfsEm30qdZ9JE7aK8vWL4PjSjZqycMuaSmBLtgJeGrMSAIj95PT5 d6HM62Le1Q8cA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C38B081707; Tue, 24 Feb 2026 15:31:31 -0500 (EST) Received: from alfajor (modemcable209.196-177-173.mc.videotron.ca [173.177.196.209]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9C93912009D; Tue, 24 Feb 2026 15:31:31 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c In-Reply-To: <86o6ld99ov.fsf@HIDDEN> Message-ID: <jwv5x7ldh6r.fsf-monnier+emacs@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> <jwvzf4z3w86.fsf-monnier+emacs@HIDDEN> <86v7fm9p4f.fsf@HIDDEN> <jwvecmadle1.fsf-monnier+emacs@HIDDEN> <86o6ld99ov.fsf@HIDDEN> Date: Tue, 24 Feb 2026 15:31:30 -0500 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.200 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: -1.3 (-) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, dancol@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: -2.3 (--) >> >> That's another option which sounds OK to me. It might break some code >> >> out there but it seems really unlikely: the usual use case is somethi= ng >> >> that wants to run code "after N seconds of idle time, and then every >> >> M seconds until the end of the idle time, after which we revert to >> >> waiting for N seconds of idle time" >> > >> > No, that's not how idle timers work. From the ELisp manual: >> > >> > Emacs becomes =E2=80=9Cidle=E2=80=9D when it starts waiting for u= ser input (unless it >> > waits for input with a timeout, *note Reading One Event::), and it >> > remains idle until the user provides some input. If a timer is set = for >> > five seconds of idleness, it runs approximately five seconds after E= macs >> > first becomes idle. Even if REPEAT is non-=E2=80=98nil=E2=80=99, th= is timer will not >> > run again as long as Emacs remains idle, because the duration of >> > idleness will continue to increase and will not go down to five seco= nds >> > again. >> > >> > The doc string of run-with-idle-timer concurs: >> > >> > If REPEAT is non-nil, do the action each time Emacs has been idle for >> > exactly SECS seconds (that is, only once for each time Emacs becomes= idle). >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^ >> > >> > Thus, each idle timer runs just once each time Emacs has been idle for >> > N seconds, and will only run again when Emacs stops being idle, and >> > then _again_ becomes idle for N seconds. >>=20 >> I'm sorry but I don't understand how what I wrote is incompatible with >> the above doc. > > The "and then every M seconds until the end of the idle time" part is > incompatible with the above documentation. Hmm... that was not discussing the way timers currently work nor the way I suggest timers should work. That was discussing a "semi-common" need. This need is typically implemented in one of two ways: - A repeating idle timer of N seconds coupled with a repeating non-idle timer of M seconds that's started from the idle timer and canceled when non-idleness is detected. - A repeating idle timer of N seconds that starts a non-repeating idle timer for N+M seconds which then starts another non-repeating idle timer for N+2*M seconds which then starts another non-repeating idle timer for N+3*M seconds which then starts another non-repeating idle timer for N+4*M seconds ... I mentioned this use-case because the second implementation is one that would be impacted by the change we propose. It's the only use case I can think of that would be impacted by the change we propose. =3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 20:19:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 15:19:14 2026 Received: from localhost ([127.0.0.1]:46446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuysE-000810-6X for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 15:19:14 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33768) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vuysC-00080f-17 for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 15:19:12 -0500 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 1vuys6-00006S-8d; Tue, 24 Feb 2026 15:19:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=oAYgZVt1Gmphtj9vyRSCa81DQ7c1xX826h6EZ+MnxTI=; b=ROMOXbhHsgxxUDFRxysL UlcgyfG4pEe91dGw4AEkS330XIsUvDl7gKmsZcik8YRjy0d83n7oypRAURAQdeeW94xRZa0qEH0ou 4PBXs6ptOIdY7LdI2Wb4MOwB+jQDRUV8Akgz7/Pl0ZJgVm3IMct+4SgXq4EVNTIcAFgL1kzszdcaP kAwGzrXoAw9PyI2FLoxqjfHN3nKQs/+S1z3w0GqjZxM7hHJ+TiFLWZFqVXXPRivs0RIv6nu3lNs41 SvuugrW077qTpCgq3zR+Kz32ynd58XBGy+nOip0V6RsDrhjO/Y7ehkdtoFwkWBmkQEjBsHDzjHVXs Z16bCnk698LFDA==; Date: Tue, 24 Feb 2026 22:18:56 +0200 Message-Id: <86o6ld99ov.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvecmadle1.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 24 Feb 2026 13:53:21 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> <jwvzf4z3w86.fsf-monnier+emacs@HIDDEN> <86v7fm9p4f.fsf@HIDDEN> <jwvecmadle1.fsf-monnier+emacs@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, dancol@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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: dancol@HIDDEN, 80468 <at> debbugs.gnu.org > Date: Tue, 24 Feb 2026 13:53:21 -0500 > > >> That's another option which sounds OK to me. It might break some code > >> out there but it seems really unlikely: the usual use case is something > >> that wants to run code "after N seconds of idle time, and then every > >> M seconds until the end of the idle time, after which we revert to > >> waiting for N seconds of idle time" > > > > No, that's not how idle timers work. From the ELisp manual: > > > > Emacs becomes “idle” when it starts waiting for user input (unless it > > waits for input with a timeout, *note Reading One Event::), and it > > remains idle until the user provides some input. If a timer is set for > > five seconds of idleness, it runs approximately five seconds after Emacs > > first becomes idle. Even if REPEAT is non-‘nil’, this timer will not > > run again as long as Emacs remains idle, because the duration of > > idleness will continue to increase and will not go down to five seconds > > again. > > > > The doc string of run-with-idle-timer concurs: > > > > If REPEAT is non-nil, do the action each time Emacs has been idle for > > exactly SECS seconds (that is, only once for each time Emacs becomes idle). > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Thus, each idle timer runs just once each time Emacs has been idle for > > N seconds, and will only run again when Emacs stops being idle, and > > then _again_ becomes idle for N seconds. > > I'm sorry but I don't understand how what I wrote is incompatible with > the above doc. The "and then every M seconds until the end of the idle time" part is incompatible with the above documentation.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 20:03:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 15:03:40 2026 Received: from localhost ([127.0.0.1]:46240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuyd9-0006s4-Pd for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 15:03:40 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:46238) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1vuyd7-0006rn-Fe for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 15:03:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=i+b8RVvH7A/zVIWp+k6f5DzgFUpHGCJid79ehogC/kE=; b=emRHWse5trINnu7RNR+lJZTob3 pJkoWqWojnjjBe87RNPzgLq2wunDh61MsVuaiNvVRy6faPz+oriuWNvmmzcVwi12d4GuzdPFGdon6 jWqE+tZN8hgMrXWVKBVKnNF2wgtyvSfANweVKJsKIncdUtYoYpl7nDj5FN71G3tbRriNli0b2HCES 1q2QJ3lUgAbkP9s/i0WuhxBXEqBDkNgWfyKfV10sj2EBfyWQsIyfKe7UVegx9uzjIiHJI7a1GOH7t HKfT/5Tpr3oKi2fMSahMukQqTc5M2lNt1NS3gCQfMtFAhA0QPk/3sx8Tsc5pr5Rh4Fk2y7907CtVj qTYZB95w==; Received: from [2600:1006:b33a:f1ee:2732:170b:a4:23d7] (port=52930 helo=localhost) by dancol.org with utf8esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from <dancol@HIDDEN>) id 1vuyd4-00000000D93-2r0I; Tue, 24 Feb 2026 15:03:34 -0500 From: Daniel Colascione <dancol@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c In-Reply-To: <jwv8qcidlc8.fsf-monnier+emacs@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <86y0ki9pnu.fsf@HIDDEN> <jwv5x7m89u2.fsf-monnier+emacs@HIDDEN> <86zf4y82vc.fsf@HIDDEN> <jwv8qcidlc8.fsf-monnier+emacs@HIDDEN> User-Agent: mu4e 1.14.0-pre1; emacs 31.0.50 Date: Tue, 24 Feb 2026 15:03:33 -0500 Message-ID: <875x7l9aei.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, Eli Zaretskii <eliz@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 (-) Stefan Monnier <monnier@HIDDEN> writes: >> In that case, I disagree with your conclusions. A non-idle timer can >> schedule another one so soon that it runs immediately. > > Of course. But the issue is not whether it's possible but whether it > occurs often enough (presumably by accident) in practice, since as we > just discussed we can't prevent all footguns. > > And my argument is that there are good reasons why it might be > reasonably common for idle timers but less so for non-idle timers. We're talking about at least three separable things. Let's discuss them separately. 1. Should *regular* timers be able to enqueue other timers in a general way? That is, should my initial motivating example cause a message to be printed at T+10s instead of T+15s? I think Eli's position is "only if we have some mechanism to recover from an Emacs locking up due to timers continually re-activating themselves with too-short (including zero) timeouts". My position, and I think Stefan's, is that we should allow it even if we don't have a solution for the lockup problem because the lockup problem belongs to the family of "doctor it hurts when I do this" things unlikely to arise by accident and inconvenience real users. 2. What should happen when an idle timer activates an idle timer while running, e.g. via (run-with-idle-timer 1 nil #'foo)? Before the 2012 fix, this code, when run from #'foo itself, would run the timer indefinitely, since the ripeness precondition of "Emacs has been idle for at least one second" would be continually met. I think we all agree this behavior is unacceptable. Current behavior is that #'foo runs one second into the current or next idleness provided we take a trip through the event loop. For example, if Emacs is idle and ordinarily wouldn't run #'foo until the next idleness, but gets a SIGCHLD, then we'll run #'foo in the current idleness after all. My position is that the code above should run #'foo during the current idleness after a one-second delay, and if the current idleness ends before one additional second has elapsed, #'foo should run one second into the next idleness. (I think Stefan agrees.) I think the running of #'foo depending on whether the event loop runs for some unrelated reason isn't useful, is surprising, and makes Emacs hard to predict. (You could imagine #'foo getting "partial credit" time spent in the current idleness, e.g. running 500ms into the next idleness if the current idleness ends after 500ms, but I don't think we need to aspire to this level of fiddlyness.) 3. Should we change the idle timer API such that repetition means what it does for regular timers instead of "re-enqueue idle timers next idleness"? This change would make idle timers easier to understand but would be a breaking change. My position is that the idle timers API could be usefully and harmlessly reinterpreted to mean a regular timer that ticks during idleness, replacing the idle-specific REPEAT semantics with regular repetition semantics. Eli is strongly against this change: he believes reinterpreting the idle timer API this way would introduce an unacceptable compatibility risk even if we can't point at one right now. --- Have I fairly characterized our positions? I personally care most about #1, since that's making me contort an unrelated project. I can concede #3. On #2, Eli, do you object strongly to changing current behavior (event loop dependent) to the behavior Stefan and I propose (event loop invariant, idle timeout interpreted as delta from present)? It's technically a breaking change, but one I think is far less risky than the change I was proposing for #3.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 19:21:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 14:21:36 2026 Received: from localhost ([127.0.0.1]:45833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuxyR-0004Pp-Ra for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 14:21:36 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13221) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vuxyP-0004PV-0Q for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 14:21:34 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 015C844232B; Tue, 24 Feb 2026 14:21:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1771960886; bh=WRFjZKG1PjOyXYYfMVT+h2v4k9Imp0QM38DH0TfSKzA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bJOhL7Qo2L9Ey5vZ7zXNtuA2yilyQjMreUdaaMsypRarRqLK5hf8lYJITKhZRTBuM ECcpa5Fx1s7epVj2hbXIaWWkEpod9gGbtABXAaxtyVZaDo0kWFJ0R1lgNtvMk9fgm6 MktPNw5t+LziNKHkxURHM99ASs9tAFT7gNe3OozJoeJcTrsd+8EgODcYtX0bjg4kzH wKHJEtWxFxEgznS1V1nRCUHvF75L2ypV9PgP5oJaD8DZN9DTUDHexOmEcShNmaJLXK 4Aq2kzcl8W0hsJC7dqFij1BcX/zakz+PSxiOE7uuyf/MbRnPyPWN/VBaWlsAODVpQk qc3kYOx7GHXKQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 16E9344230F; Tue, 24 Feb 2026 14:21:26 -0500 (EST) Received: from alfajor (modemcable209.196-177-173.mc.videotron.ca [173.177.196.209]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DBDF51201DD; Tue, 24 Feb 2026 14:21:25 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c In-Reply-To: <86zf4y82vc.fsf@HIDDEN> Message-ID: <jwv8qcidlc8.fsf-monnier+emacs@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <86y0ki9pnu.fsf@HIDDEN> <jwv5x7m89u2.fsf-monnier+emacs@HIDDEN> <86zf4y82vc.fsf@HIDDEN> Date: Tue, 24 Feb 2026 14:21:25 -0500 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.122 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: -1.3 (-) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, dancol@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: -2.3 (--) > In that case, I disagree with your conclusions. A non-idle timer can > schedule another one so soon that it runs immediately. Of course. But the issue is not whether it's possible but whether it occurs often enough (presumably by accident) in practice, since as we just discussed we can't prevent all footguns. And my argument is that there are good reasons why it might be reasonably common for idle timers but less so for non-idle timers. === Stefan
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 18:53:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 13:53:31 2026 Received: from localhost ([127.0.0.1]:45644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuxXH-0002Xg-FR for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 13:53:31 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63093) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vuxXE-0002XO-PU for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 13:53:29 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 394BC100146; Tue, 24 Feb 2026 13:53:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1771959202; bh=IcI9JkYDPFzaMKV5lihxUij73r2Va62Q8ncQd5Geosk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZjrnUeeGoePbIbo9h5XL9qBKrWkI8OgDL/Kn18nGYPKIjTiduBMFsANQMoekaeJ5Z iNV08LhyKdKnZoaGjEkGYaQcq9o9+uOa2RZ3IrhrA5X6OCUtXTenL5UfDXCX/sMYwe UNiqgQ6SrJzfdFrbOYlNvtGYqt622cfgpFAWSL7fZPsTmswbYGpcLI4Nsi2fYpj0Ft 0lFCHbQqiJXW3pt74ukgWc+dV/4bFADmhJE/FRRTSOOGQNHdyye3JX0+ZGShHXcSp5 WorlEk4RejfVhi8+5z9fbZZpNyyvSCK8FPFBABzmmTf3qr/LZDn/OzPWGIK+ZdiyCJ ETqjvm1Un6sxA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2199A100034; Tue, 24 Feb 2026 13:53:22 -0500 (EST) Received: from alfajor (modemcable209.196-177-173.mc.videotron.ca [173.177.196.209]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0027412048A; Tue, 24 Feb 2026 13:53:21 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c In-Reply-To: <86v7fm9p4f.fsf@HIDDEN> Message-ID: <jwvecmadle1.fsf-monnier+emacs@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> <jwvzf4z3w86.fsf-monnier+emacs@HIDDEN> <86v7fm9p4f.fsf@HIDDEN> Date: Tue, 24 Feb 2026 13:53:21 -0500 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.148 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: -1.3 (-) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, dancol@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: -2.3 (--) >> That's another option which sounds OK to me. It might break some code >> out there but it seems really unlikely: the usual use case is something >> that wants to run code "after N seconds of idle time, and then every >> M seconds until the end of the idle time, after which we revert to >> waiting for N seconds of idle time" > > No, that's not how idle timers work. From the ELisp manual: > > Emacs becomes =E2=80=9Cidle=E2=80=9D when it starts waiting for user= input (unless it > waits for input with a timeout, *note Reading One Event::), and it > remains idle until the user provides some input. If a timer is set for > five seconds of idleness, it runs approximately five seconds after Emacs > first becomes idle. Even if REPEAT is non-=E2=80=98nil=E2=80=99, this = timer will not > run again as long as Emacs remains idle, because the duration of > idleness will continue to increase and will not go down to five seconds > again. > > The doc string of run-with-idle-timer concurs: > > If REPEAT is non-nil, do the action each time Emacs has been idle for > exactly SECS seconds (that is, only once for each time Emacs becomes id= le). > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^ > > Thus, each idle timer runs just once each time Emacs has been idle for > N seconds, and will only run again when Emacs stops being idle, and > then _again_ becomes idle for N seconds. I'm sorry but I don't understand how what I wrote is incompatible with the above doc. =3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 18:21:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 13:21:51 2026 Received: from localhost ([127.0.0.1]:45403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vux2c-0000v7-P9 for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 13:21:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45302) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vux2Y-0000ur-IU for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 13:21:49 -0500 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 1vux2S-0004dP-5u; Tue, 24 Feb 2026 13:21:40 -0500 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=y9L7rGQyd6DsLREANl2GXvyFz6KK9Fve/eBzJYrN09w=; b=iu99zNo52nuY oqA9GpFXIT++dJpEbNORrDqbhIf26LhakIGTEuNdvH0ujAwfj8vlncH4i9o6KR+r1x2z/J1N4U5AL q2mFEmsFNPAy5l0Q+f74EOsq5Xu6Gmmv6lIykdjRlr4qYmd9sHLJmknNoJQOOCF6yxYWSoFRHBsCs 5GYg9nkKy5oEuYOcTMTXzRkMG7nfzcRl9rIQ1CwYB2AhybjWYDVLj2gw8mexrCR9rFJpqdJFr/gI3 Lb5SJvY7PWqxZv/tyjlxBj2U130UpBbEpdsStq7vyJ8y3c2IrdTNtbSnPWkxh0r2LkTF55HDzkOfu zdqEs8AKzTDoP6AXWTMXvA==; Date: Tue, 24 Feb 2026 20:19:42 +0200 Message-Id: <86tsv680n5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> In-Reply-To: <9E2E73E4-DDC6-42B9-A085-94AE970E64C6@HIDDEN> (message from Daniel Colascione on Tue, 24 Feb 2026 12:43:02 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <86y0ki9pnu.fsf@HIDDEN> <jwv5x7m89u2.fsf-monnier+emacs@HIDDEN> <861pia9hyg.fsf@HIDDEN> <9E2E73E4-DDC6-42B9-A085-94AE970E64C6@HIDDEN> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, 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: -3.3 (---) > Date: Tue, 24 Feb 2026 12:43:02 -0500 > From: Daniel Colascione <dancol@HIDDEN> > CC: 80468 <at> debbugs.gnu.org > > Idleness intervals are not contractual anyway. Who's to say "the current idleness" doesn't end in one second and a new "idleness" start the next? We never made any precise promises about what idleness means. We never make (and cannot make) promises about their timeliness, that's true. But many/most uses of idle timers don't care about timeliness, they care about the amount of time Emacs was idle. This allows us to have features that perform some routine tasks while avoiding to do them too frequently and/or without getting in the way of user commands. Example: auto-saving. > The idle timer mechanism is itself just a crude and imperfect approximation of what people really want, which is that Emacs be able to do background work in such a way that it not interfere with interactively-issued commands. Because the idle timer mechanism is just a heuristic to approximate background work, we should be free to tweak the heuristic however we want, and nobody should interpret idle timer behavior as a strict contract. If we were talking back when timers in their current form were added to Emacs 19, this could be a valid argument. But we are many years past that point, and by now the way idle timers work is a de-facto standard. If you want something radically different, why not implement a new kind of timer, instead of arguing about such changes in long-standing behavior? > "I can't think of something this change would practically break, but we can't make it because it changes something" cannot be the bar for fixes to a living system. Since every behavior is observable, such a bar means the system gets frozen in amber. I wish the spacebar heating joke were just a joke. The system isn't frozen, but some long-standing aspects of it are. We cannot in our right minds change such basic mechanisms in Emacs! There are 80 callers of run-with-idle-timer in Emacs alone. So if we must have idle timers with different behavior, let's have a new API, like run-with-idle-timer2 or somesuch. Then everyone will be able to have their cake and burn it as they see fit.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 17:43:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 12:43:10 2026 Received: from localhost ([127.0.0.1]:45114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuwRB-0007Eu-JL for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 12:43:10 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:34256) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1vuwR8-0007Ej-MN for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 12:43:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=FstMmFVE0QgC9TJAMNa9xrWoxyGqJsJm2n4Az1O116o=; b=R0c8CNXgC4eLl4S+Z4Ebcf2BHH mvPcvzAKoF2tvrxMotPKZ7mYlrzEUw0dj+dtqiR0W63rpX6Nvl5YRzGRU5dH6CHf3AP5pqw4T4b6y PfFDoirG5Aqv5bDY91DgjB3Nv83q9y3voGzSPBiVF/Dgrr92GWqirYIgqYWqYvV4xGG9fTtWYpkaI L5cFeaW1HkcZ9Uzj6P0LAM4G4/5k14fY/jdaafQKJyOzqflI2MU/gp7S/nspYDWfRwNEYhPV2+jc9 vz43VRTYi+wDBgNzetY//3cONJrmEeDLcoOoTLmaFRFP4zYw7RlJQejs+buN4J5K3QbKl/A1CSsTE s9GATIYg==; Received: from [72.185.139.69] (port=43510 helo=ehlo.thunderbird.net) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from <dancol@HIDDEN>) id 1vuwR5-00000000Cjn-25Og; Tue, 24 Feb 2026 12:43:03 -0500 Date: Tue, 24 Feb 2026 12:43:02 -0500 From: Daniel Colascione <dancol@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2380468=3A_Timers_cannot_enqueu?= =?US-ASCII?Q?e_timers_overly_cautious_keyboard=2Ec?= User-Agent: K-9 Mail for Android In-Reply-To: <861pia9hyg.fsf@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <86y0ki9pnu.fsf@HIDDEN> <jwv5x7m89u2.fsf-monnier+emacs@HIDDEN> <861pia9hyg.fsf@HIDDEN> Message-ID: <9E2E73E4-DDC6-42B9-A085-94AE970E64C6@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 80468 Cc: 80468 <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 (-) On February 24, 2026 12:20:23 PM EST, Eli Zaretskii <eliz@gnu=2Eorg> wrote= : >> From: Stefan Monnier <monnier@iro=2Eumontreal=2Eca> >> Cc: dancol@dancol=2Eorg, 80468@debbugs=2Egnu=2Eorg >> Date: Tue, 24 Feb 2026 10:08:18 -0500 >>=20 >> >> And maybe a better fix for the bug#12326 and bug#12447 is to change >> >> `run-with-idle-timer` so it checks if the scheduled time is in the p= ast >> >> or the future, and if it's in the past delay the modification of >> >> `timer-idle-list` to after the end of the current idleness=2E >> > That's a radical change in behavior=2E Currently, each idle timer is >> > invoked, once, whenever Emacs has been idle for enough time=2E >>=20 >> More or less, yes (your 2012 patch delays running the timer in some >> cases)=2E With the discussed change that would still hold, except for = the >> really unusual case where the new idle timer starts in the past (but >> "run once" idle timers would still be run exactly once, just not >> during the current idleness if they're scheduled into the past)=2E >> Daniel's variant would keep the behavior closer to the one we currently >> have=2E >>=20 >> > With your proposed change, an idle timer can be delayed until the nex= t >> > idleness, >>=20 >> Only if it's scheduled into the past=2E >> Can you think of examples where ELisp packages might do that (and care >> if it's run in the current idleness)? > >I don't know any off-hand, but that shouldn't matter for such an >obvious change in behavior=2E We cannot make such changes, sorry=2E Idleness intervals are not contractual anyway=2E Who's to say "the current= idleness" doesn't end in one second and a new "idleness" start the next? W= e never made any precise promises about what idleness means=2E The idle timer mechanism is itself just a crude and imperfect approximatio= n of what people really want, which is that Emacs be able to do background = work in such a way that it not interfere with interactively-issued commands= =2E Because the idle timer mechanism is just a heuristic to approximate bac= kground work, we should be free to tweak the heuristic however we want, and= nobody should interpret idle timer behavior as a strict contract=2E "I can't think of something this change would practically break, but we ca= n't make it because it changes something" cannot be the bar for fixes to a = living system=2E Since every behavior is observable, such a bar means the s= ystem gets frozen in amber=2E I wish the spacebar heating joke were just a = joke=2E
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 17:32:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 12:32:11 2026 Received: from localhost ([127.0.0.1]:45008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuwGZ-0006ds-4x for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 12:32:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36886) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vuwGW-0006dY-EN for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 12:32:09 -0500 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 1vuwGP-0002mE-B7; Tue, 24 Feb 2026 12:32:02 -0500 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=cPsDjAxtwK0dFn4qMVycwbyWRBmUNDSDlYMx3CB7tYA=; b=Of2OUfd+H4tz xK6HaEztk2cNE7uiUyDPxKyfgkTau+9iM2FmbmodlxjlFwrMW9PfwKJxs57MCTa2TFTq+dMAY4JAN QR0XbZCUuw6r29xLoJ4dF/PVORdyQcFXvwHEEdZ4iu1OGDVxwAzKeYevUmG2qP3aw9+YAG4Izv4HM R8tOKIvK0ctw7wpFJUNHVPEAbuqYr49n66EPRMMW64iI2DBXbIOL59d/VZHZWnVC1uy63k79foRwv 4pW7hSYvQKdO9tyNH0Mwn+0R+iS/gb5ytjIQGNPChcNGELGPlGt0cpBSbv+lSna+iVXUY4NOmIHPL lB4nCAAHFw9nT7u7EiHP7A==; Date: Tue, 24 Feb 2026 19:31:35 +0200 Message-Id: <86zf4y82vc.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv5x7m89u2.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 24 Feb 2026 10:08:18 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <86y0ki9pnu.fsf@HIDDEN> <jwv5x7m89u2.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, dancol@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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: dancol@HIDDEN, 80468 <at> debbugs.gnu.org > Date: Tue, 24 Feb 2026 10:08:18 -0500 > > >> In contrast (run-with-idle-timer TIME ...) schedules the timer to run > >> at "start-of-idle + TIME", which sounds like (and usually is) a relative > >> time in the future, but when called while idle, it is basically an > >> absolute time that can be in the past just as much as in the future, > >> much to the surprise of the caller. > > > > Are you sure this is the reason? > > Not 100%, but pretty close. > > > AFAIU, the reason is different, it's because timer_check does: > > AFAICT, you're talking about the problem that Daniel is complaining > about, whereas I'm talking about the problem fixed by your 2012 patch. In that case, I disagree with your conclusions. A non-idle timer can schedule another one so soon that it runs immediately. The probability of this becomes higher if the timer is delayed because of some expensive command. And scheduling idle timer can predictably know whether the new timer it schedules will run immediately or not, by comparing its TIME with the TIME of the other timer. So I see no significant differences between the two types of the timers, in this particular context, and therefore conclude (as I did back then) that the copying of the timer-list is needed in both cases to prevent bad freezes.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 17:20:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 12:20:39 2026 Received: from localhost ([127.0.0.1]:44924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuw5P-00063y-An for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 12:20:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52432) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vuw5M-00063c-Jc for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 12:20:38 -0500 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 1vuw5F-0000bz-Lm; Tue, 24 Feb 2026 12:20:30 -0500 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=i8oTEAEkRJGqm9dlJhuBeFB0TH34GnNVF8RW+x44YHY=; b=fupw7ks3iXE+ OUgJzkvITgd16SMMFv4cbQUjw1eXMlE02Fn/hfvx+wFJ0YAdPEwf6RrqPgrQAr+oCYHOu35BDuMwE Bm0PmoJh+7MXAJnEv44//9BZSZ/TSOlXs6fW1j9u7rSg/dbIeo1oNtG5HZ0kP51V+7XTlxeW3645p hc97KUt1MCNEUbiUQpaBxUYHqBtJI3ic0orVIj+eu7jlFuD9JFHJHnqWEK3kOcfg3DCax2U2PZs1B dtcqmZLPc3lXVQk+ac10eRQaNtgKjVUjs4wJm5ObJFPSwpz1hSImgVQKd0EqCJdMRLn6sf0D52kP6 yUn+rPlSUtZrL6SfK4fdEQ==; Date: Tue, 24 Feb 2026 19:20:23 +0200 Message-Id: <861pia9hyg.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv5x7m89u2.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 24 Feb 2026 10:08:18 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <86y0ki9pnu.fsf@HIDDEN> <jwv5x7m89u2.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, dancol@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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: dancol@HIDDEN, 80468 <at> debbugs.gnu.org > Date: Tue, 24 Feb 2026 10:08:18 -0500 > > >> And maybe a better fix for the bug#12326 and bug#12447 is to change > >> `run-with-idle-timer` so it checks if the scheduled time is in the past > >> or the future, and if it's in the past delay the modification of > >> `timer-idle-list` to after the end of the current idleness. > > That's a radical change in behavior. Currently, each idle timer is > > invoked, once, whenever Emacs has been idle for enough time. > > More or less, yes (your 2012 patch delays running the timer in some > cases). With the discussed change that would still hold, except for the > really unusual case where the new idle timer starts in the past (but > "run once" idle timers would still be run exactly once, just not > during the current idleness if they're scheduled into the past). > Daniel's variant would keep the behavior closer to the one we currently > have. > > > With your proposed change, an idle timer can be delayed until the next > > idleness, > > Only if it's scheduled into the past. > Can you think of examples where ELisp packages might do that (and care > if it's run in the current idleness)? I don't know any off-hand, but that shouldn't matter for such an obvious change in behavior. We cannot make such changes, sorry. > > or even indefinitely. > > I don't know what makes you think so. What scenario do you have in mind > where this would happen? That idleness doesn't come until much later.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 15:10:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 10:10:55 2026 Received: from localhost ([127.0.0.1]:43617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuu3q-0006AU-SA for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 10:10:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51188) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vuu3n-00069m-Pj for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 10:10:52 -0500 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 1vuu3h-0007bk-KU; Tue, 24 Feb 2026 10:10:46 -0500 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=HrDSMQ1fbrai6rW23iwuVQ6x2pL2i40dmHDQKDPxoQM=; b=ra88Pt9psKk2 ursthoBe/w38X0eVSkZjkNQ2tDt/+ye6Piwg9PT+CnuDcwcxOw27Xc6wCyGQ4H1NBxEK04dpNE218 T5miUQd3qHb3v122dPW17AhpQfQbOtmBot95BeKyi8pa390bLhYIpVakJgWNvhYZlhHgdEZZxgJxN QCKa8mL47swSSyxI562fLYz9GcS1glmRW9la5+cWV/u/hq5d2VHOoJpgSH3nGTLUNKWAH76DBT4fw ghNIu+gL8fzCGSbrwSwN6z6c7YV0vXddrSdaU+gHIW9c+fKbAmzUB8l7AUqYjirQYYzc13rHPSNBT Uk2NRJNlsABlm3d62XyqYQ==; Date: Tue, 24 Feb 2026 17:10:15 +0200 Message-Id: <86seaq9nzc.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> In-Reply-To: <87bjhf7z1d.fsf@HIDDEN> (message from Daniel Colascione on Mon, 23 Feb 2026 19:42:06 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> <jwvzf4z3w86.fsf-monnier+emacs@HIDDEN> <87bjhf7z1d.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, 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: -3.3 (---) > From: Daniel Colascione <dancol@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 80468 <at> debbugs.gnu.org > Date: Mon, 23 Feb 2026 19:42:06 -0500 > > What do you think of simplifying it like this? The "real" idle timer is > an entry on timer-idle-list. When we enter an idle period, each idle > timer creates for itself an internal non-idle regular timer that runs > the user-specified idle timer function. This internal regular timer > works like any other regular timer with respect to initial delays and > repetition. When we exit an idle period, we cancel each idle timer's > internal timer, but leave the idle timer itself (the entry on > timer-idle-list) alive, and on entry to the next idle period, we have it > create a new regular timer for that idle period. I don't think I see how this is different from what we have now, wrt to the problem of timers scheduling other timers. What am I missing? > Granted, run-with-idle-timer currently says "If REPEAT is non-nil, do > the action each time Emacs has been idle for "exactly SECS seconds (that > is, only once for each time Emacs becomes idle)", but I don't think we'd > break anything by switching to the model I described above. If you mean that, under your proposal, idle timers will run more than once per idleness period, then it's a very significant change in behavior, and I don't think we should make it. For example, consider stuff that runs off idle timers now, like auto-save: we don't want to run it more than once per idleness period. > We might fix things by side effect too. For example, WDYT is the actual > intent of this code? > > (unless url-queue-progress-timer > (setq url-queue-progress-timer > (run-with-idle-timer 1 1 #'url-queue-check-progress))) > > Intuitively, I'd expect that to mean "run this function once per second > while Emacs is idle, starting one second after Emacs becomes idle". No, it means run it 1 sec after Emacs becomes idle, then don't run it again until Emacs becomes idle again. The argument REPEAT is only tested for being nil or non-nil, so 1 is the same as t. > If we really want to exactly match the current API instead of implement > the model above, we can do that too, but the current model feels like of > silly to me. It is far from being silly. It fits what we want from features that use idle timers in Emacs, see above for one example.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 15:08:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 10:08:35 2026 Received: from localhost ([127.0.0.1]:43552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuu1Y-0005vI-Qo for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 10:08:35 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8367) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vuu1S-0005tg-UL for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 10:08:29 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 585D54422BF; Tue, 24 Feb 2026 10:08:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1771945699; bh=wjFHl8ni9tSahRKvOoCjgELo8RhQ6uZtur4q0rs1yHI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KYHE9oVLuRe7Oi0CMFg4W4vxZ65oyXv60n7g1drahZtoSUnURJu6S9vLNUo44KsVs AySxzHuW0FXMsIzXv54T39GkiWqEsbLs4U5JmkwBKjzHONOob8mOiJB0Ty1ehqwhFG gsjflGHINYPL8BtFbrO/R+OGMvJADcAU7LSj9xorB/d0/9vRDeR8qMCoIsi1fReGAD jA3OWdA1tbouC4jjqVOjX/JzrOxI2XU5uWn0/weRTMWJL/QDmqcnV+N2fvH4MqswO2 0JmupXbftojXDVFlP7z4jZAwZlIf/1dZedO6J9dTKlpZ4d8UvdjKQTRLx4lK4o6+U3 T9fmdlcNeOWbA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 33F4C4422BD; Tue, 24 Feb 2026 10:08:19 -0500 (EST) Received: from pastel (104-195-208-210.cpe.teksavvy.com [104.195.208.210]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EF68B120970; Tue, 24 Feb 2026 10:08:18 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c In-Reply-To: <86y0ki9pnu.fsf@HIDDEN> Message-ID: <jwv5x7m89u2.fsf-monnier+emacs@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <86y0ki9pnu.fsf@HIDDEN> Date: Tue, 24 Feb 2026 10:08:18 -0500 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.190 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: -1.3 (-) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, dancol@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: -2.3 (--) >> In contrast (run-with-idle-timer TIME ...) schedules the timer to run >> at "start-of-idle + TIME", which sounds like (and usually is) a relative >> time in the future, but when called while idle, it is basically an >> absolute time that can be in the past just as much as in the future, >> much to the surprise of the caller. > > Are you sure this is the reason? Not 100%, but pretty close. > AFAIU, the reason is different, it's because timer_check does: AFAICT, you're talking about the problem that Daniel is complaining about, whereas I'm talking about the problem fixed by your 2012 patch. >> And maybe a better fix for the bug#12326 and bug#12447 is to change >> `run-with-idle-timer` so it checks if the scheduled time is in the past >> or the future, and if it's in the past delay the modification of >> `timer-idle-list` to after the end of the current idleness. > That's a radical change in behavior. Currently, each idle timer is > invoked, once, whenever Emacs has been idle for enough time. More or less, yes (your 2012 patch delays running the timer in some cases). With the discussed change that would still hold, except for the really unusual case where the new idle timer starts in the past (but "run once" idle timers would still be run exactly once, just not during the current idleness if they're scheduled into the past). Daniel's variant would keep the behavior closer to the one we currently have. > With your proposed change, an idle timer can be delayed until the next > idleness, Only if it's scheduled into the past. Can you think of examples where ELisp packages might do that (and care if it's run in the current idleness)? > or even indefinitely. I don't know what makes you think so. What scenario do you have in mind where this would happen? === Stefan
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.
Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 14:46:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 09:46:51 2026
Received: from localhost ([127.0.0.1]:42311 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vutgY-0004Tx-1i
for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 09:46:51 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:48900)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vutgW-0004T5-1J
for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 09:46:48 -0500
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 1vutgQ-0003Rc-Ey; Tue, 24 Feb 2026 09:46:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=X8R3RmLFcMY1hmG/Fe/Xp3I387tjj8Pza6/2qkrDu9A=; b=EyxEB0wFJWcTBmweUDwO
8/7OKAUOBIjz17Qn3eaMj7Y7AZUZp4VW9qwMCwFnBGFo6ZqxTUFkt5I9GOJdi0v367RpkCGNf8SwT
njzET8f6z/VQJHPatoPYjHyM2c+z/wDg+Hzya8PhD5GBSGP6ACLU27d0tnpvJ/OutFx5gjZeUi+NV
4fkZUUdReFDnzIA90sJtBscjhqIpAuTqWnTTnEj1PmBt68AnRaW0us2ioYhDUg8H5okQJMhnPFii9
KHEgTRlGTDG5xJn0Q8XC1KsPFI1PFXQEdah7PTBKrzom17miJIq+E3TlgX5vf9JKJy4PeuW29PB6/
A05Z7yjbax5jDQ==;
Date: Tue, 24 Feb 2026 16:45:36 +0200
Message-Id: <86v7fm9p4f.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvzf4z3w86.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Mon, 23 Feb 2026 18:08:27 -0500)
Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c
References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN>
<jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN>
<ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN>
<jwvzf4z3w86.fsf-monnier+emacs@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80468
Cc: 80468 <at> debbugs.gnu.org, dancol@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 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 80468 <at> debbugs.gnu.org
> Date: Mon, 23 Feb 2026 18:08:27 -0500
>
> > ... it's still kind of weird that the effect of scheduling a timer
> > enablement depends on the fine details of the context in which it's
> > enqueued. Would it break anything to interpret the idle timeout of N as
> > relative to the present if already idle?
>
> That's another option which sounds OK to me. It might break some code
> out there but it seems really unlikely: the usual use case is something
> that wants to run code "after N seconds of idle time, and then every
> M seconds until the end of the idle time, after which we revert to
> waiting for N seconds of idle time"
No, that's not how idle timers work. From the ELisp manual:
Emacs becomes “idle” when it starts waiting for user input (unless it
waits for input with a timeout, *note Reading One Event::), and it
remains idle until the user provides some input. If a timer is set for
five seconds of idleness, it runs approximately five seconds after Emacs
first becomes idle. Even if REPEAT is non-‘nil’, this timer will not
run again as long as Emacs remains idle, because the duration of
idleness will continue to increase and will not go down to five seconds
again.
The doc string of run-with-idle-timer concurs:
If REPEAT is non-nil, do the action each time Emacs has been idle for
exactly SECS seconds (that is, only once for each time Emacs becomes idle).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Thus, each idle timer runs just once each time Emacs has been idle for
N seconds, and will only run again when Emacs stops being idle, and
then _again_ becomes idle for N seconds.
So the change you propose is quite a serious change in behavior, and I
don't think we should make it.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 14:37:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 09:37:29 2026 Received: from localhost ([127.0.0.1]:42213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vutXU-0003tN-Ji for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 09:37:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51502) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vutXT-0003tB-5Q for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 09:37:27 -0500 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 1vutXN-0000kI-Rk; Tue, 24 Feb 2026 09:37:21 -0500 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=4Xip3zDqDEI2Vaf/yCmhq0tiLEVg8nBPt0wDbvExclg=; b=GCoWPqKfzC6Q ThmKwUJVCm9cRw6kU+EKSKykK9ZUPi3hBn6gN5QVn5iII5+OBFtWiOoTuqD177ch/JKaB3P7GIGdC 05UDlnyTMZiY1OxU8TMxL8IRmIgb9kPgPr1Q2lOIZHAgQrf+3GSoRYVRXv31n23+ALxeS6H9L/Hza C9z2KRTEaLRQQ3iw80OQ1j5mDnv6iIbJtVdFiyVNHRZ5oCNqJwDN43GsrYmnCKVM7ES+epZZHyvsw q6HUqZz3UpqCU2LqH/ol0DUK4RlW6fV6tf55fLvqGh2+1q9WxHdRb1gsuFsfYWDcfIRKTrOddWhJo yJZWsz6wyHaxhXtYMLtXuw==; Date: Tue, 24 Feb 2026 16:37:19 +0200 Message-Id: <86wm029pi8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> In-Reply-To: <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> (message from Daniel Colascione on Mon, 23 Feb 2026 17:48:56 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, 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: -3.3 (---) > Date: Mon, 23 Feb 2026 17:48:56 -0500 > From: Daniel Colascione <dancol@HIDDEN> > CC: 80468 <at> debbugs.gnu.org > > You could just define, I think, idle timers as timers activated in some hypothetical emacs-idle-start hook and canceled again in an emacs-idle-end hook. An idle timer added between the two hooks would be activated immediately (and still canceled in emacs-idle-end). Isn't that what happens now? I thought it was, and that's why the original bugs caused lockups. Or what am I missing?
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.
Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 14:34:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 09:34:48 2026
Received: from localhost ([127.0.0.1]:42192 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vutUt-0003iv-9S
for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 09:34:47 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:38132)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vutUp-0003ia-9h
for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 09:34:45 -0500
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 1vutUh-0000K2-EZ; Tue, 24 Feb 2026 09:34:36 -0500
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=p5yEb+wyRNjZ4WReQlIK4UG/Pe3rV05omyTwC1X+J28=; b=BaUPxb1JIfpm
hykuHhG5Q9sgapgL+ja22NR/IKQpb/8ZAW8460VfiCB9JcvCgCIBAiOrcXzeg7HzC1VyZBMJ7WdVX
oNtQqy31N3kVaJ4eqbSeMNYsRU+zmxuonryPA7HQM83oDNG5z0mN+aCOlmveOBX5/lbYOuJ5d8RPo
fFzJ+QiUSHh5wzE1HYRL0SogmYkhNJZeGSZyxxO4rqItLfM9dExnrvq0Cezj15wIvLo0Qt0Lr2O6j
+LDgVGhzdDQwWY6jsVO5eH/pC/UtOO4pKYAdTQz17TNaisn1ooeMBXVj9Jlmt4W4qFAEHcMLaBZn5
nLxvphPQqvgp1QIF+m/FQQ==;
Date: Tue, 24 Feb 2026 16:33:57 +0200
Message-Id: <86y0ki9pnu.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Mon, 23 Feb 2026 17:26:58 -0500)
Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c
References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN>
<jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80468
Cc: 80468 <at> debbugs.gnu.org, dancol@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 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Daniel Colascione <dancol@HIDDEN>, 80468 <at> debbugs.gnu.org
> Date: Mon, 23 Feb 2026 17:26:58 -0500
>
> > If you or someone can find a way of doing the above without the
> > downsides that the 2012 change tried to prevent, please show the code,
> > and let's take this from there. (Personally, I don't think I
> > understand how re-scanning Vtimer_list will not bring us back the bad
> > problems which working on a copy was supposed to prevent, but maybe
> > I'm missing something.)
>
> AFAICT the problem that commit fixed appears only for idle timers.
>
> This is because (run-with-timer TIME ...) schedules the new timer to run
> at time "now + TIME", so it's pretty obvious to the caller whether the
> scheduled time is in the past or in the future.
>
> In contrast (run-with-idle-timer TIME ...) schedules the timer to run
> at "start-of-idle + TIME", which sounds like (and usually is) a relative
> time in the future, but when called while idle, it is basically an
> absolute time that can be in the past just as much as in the future,
> much to the surprise of the caller.
Are you sure this is the reason? AFAIU, the reason is different, it's
because timer_check does:
do
{
nexttime = timer_check_2 (timers, idle_timers);
}
while (nexttime.tv_sec == 0 && nexttime.tv_nsec == 0);
return nexttime;
and timer_check_2 returns the "next time to check for timers" that
doesn't account for the new timer scheduled by the timer function that
timer_check_2 just invoked (since it works on a copy of the timers'
list, and that copy doesn't include the newly-added timer).
So in Daniel's example, timer_check_2 returns the time 10 sec in the
future to check for timers, but the new timer just scheduled should
become ripe in 5 sec, not in 10.
If I'm right, this has very little to do with idle timers.
> So maybe a good workaround for now is to refrain from calling
> `copy-sequence` on the `timer-list`, i.e. call it only for
> `timer-idle-list.`
A non-idle timer can schedule itself or another timer soon enough to
prevent timer_check from finishing, and we are back at the original
problem.
> And maybe a better fix for the bug#12326 and bug#12447 is to change
> `run-with-idle-timer` so it checks if the scheduled time is in the past
> or the future, and if it's in the past delay the modification of
> `timer-idle-list` to after the end of the current idleness.
That's a radical change in behavior. Currently, each idle timer is
invoked, once, whenever Emacs has been idle for enough time. With
your proposed change, an idle timer can be delayed until the next
idleness, or even indefinitely. I'd object to such a change.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 13:22:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 08:22:17 2026 Received: from localhost ([127.0.0.1]:41547 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vusMj-0007hX-6j for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 08:22:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47428) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vusMf-0007h4-Uu for 80468 <at> debbugs.gnu.org; Tue, 24 Feb 2026 08:22:15 -0500 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 1vusMZ-0004Ci-KB; Tue, 24 Feb 2026 08:22:07 -0500 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=eWhuhXSs95goCexIeewVY2X3oy5DUslyD5AzTNkh3hA=; b=ac4oMEFs87Uu pHpGh3dglHYrupLoTevRYaMkNwJR8w0gVbN5tHJ5rmQiTL/WB1f4jX7Ti2gnnAMkFdNh1sYZN960X I+4nrP9Ng/wVpSspqY6wpHydYkwDuQDrdIZ9oPOHXHaWnEfzzd9SmLREX8canjQMiG9dmWt07cNq4 /8Sa9yKFuvpeb3fM+GV2APBouW/IgQfcdpO8U+OAXI0ISiqAv4IML8tk8NyVRy0ybwLohXol9taMM AFGWYl4TPJA/4BUpJ1yBBQQBWnmuCVNoSueRbIy/0Af/PKgdbQVI4bORG7P/6SC4cX9ukUduF9Ps7 ElzcQu8oPfHDnWSZput4Eg==; Date: Tue, 24 Feb 2026 15:22:03 +0200 Message-Id: <867bs2b7k4.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> In-Reply-To: <87ldgj6xbz.fsf@HIDDEN> (message from Daniel Colascione on Mon, 23 Feb 2026 15:04:16 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <5eec8ae0ccdddc2e4d1dfe63ebe53d9c@HIDDEN> <86ecmbbahz.fsf@HIDDEN> <87ldgj6xbz.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, 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: -3.3 (---) > From: Daniel Colascione <dancol@HIDDEN> > Cc: 80468 <at> debbugs.gnu.org, monnier@HIDDEN > Date: Mon, 23 Feb 2026 15:04:16 -0500 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> One can DoS Emacs in numerous ways. Why is it imperative so imperative > >> to prevent this failure mode that we make it impossible to perform this > >> natural operation with timers? > > > > I presume you've read those two bugs, so you know what was the > > "failure mode" in those cases: continuous GC with high CPU usage in > > one case and a complete freeze in the other. Sounds grave enough to > > me. > > Sure, but I can already make Emacs lock up any time I want with a single > sexp. :-) It's just (setf inhibit-redisplay t). I don't think we > consider this a bug, because it's a "doctor, it hurts when I do this" > situation. Exactly. Locking up Emacs because of silly things can be defended, but even so, we sometimes install changes for even the silly things, because what is silly to me and you is not necessarily clearly silly to someone who knows less than we do about how Emacs internals work. E.g., people were known to delete the window being scrolled from within window-scroll-functions. Silly enough to give them the "don't do that" response? > I think most of the pathological timer-loops-run-forever > things are similar. What I get out of bug#12447 in particular is that > natural idioms like this > > > (defun foo () > (message (format "foo %s" counter)) > (setq counter (1+ counter)) > (run-with-idle-timer 1 nil #'foo)) > (foo) > > shouldn't lock up Emacs. Can't we do something like impose a maximum > frequency (say, 1Hz) on idle timers while people let themselves do silly > things with regular timers if they really want? Then someone like you will come up complaining that we artificially restrict his/her legitimate code. How can we explain, let alone defend, such artificial limitations on modern machines, where a second is almost an eternity? > I'd also just move the whole timer loop to Lisp so it's easier to work > with. Not sure why timer_check_2 needs to be in C anyway. We'd also be > able to get rid of the O(N^2) recheck loop and the per-timer-check > consing at the same time. (The latter is much less an issue with our > fancy new GC, but still ugly.) We can move it to Lisp, but it must be called from C. And timers are supposed to be very efficient, so doing that in Lisp might get in the way. In any case, I think this is almost orthogonal to the main issues at hand.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 04:39:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 23:39:00 2026 Received: from localhost ([127.0.0.1]:35258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vukCK-0004P6-IJ for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 23:39:00 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37059) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vukCH-0004Nz-1C for 80468 <at> debbugs.gnu.org; Mon, 23 Feb 2026 23:38:58 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2E5B910013E; Mon, 23 Feb 2026 23:38:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1771907929; bh=TA4jPyXeL2woxtDPPGTkGlqmndBjouM3556c2pyEQ8Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=eRc9WwWvMFCAy++EqR80zL4lVItoM4MqVw2LfpD48KGlCNYP5SI1zVkISPGVUg4r5 AQZDASZ5g1GaaUERJSxqBOOjDI1un6jEJ8VT/J/gLePUwrTuPfvh8s98Hi/8LWLsm6 Ol6WsfCSigiOBSAxTBbGl7N7y9Afs5bBv4AESLtaQS0KBzc6iEdDthjRtmwcwsj/4J IzxIbOQruX9RPiguVGkUhw6YgZ+UmmFDxkgA1L14XnUkXiMovPlDOdDQ260RpjTWUT AcrsU4cVmKUXAJbg85sBJEbjeoorgi8/MCt4xkKHy6qVaut339WhkGt8FGgKU0IQo6 8rbFJN8xTPsgw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0662210002D; Mon, 23 Feb 2026 23:38:49 -0500 (EST) Received: from pastel (104-195-208-210.cpe.teksavvy.com [104.195.208.210]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C83CB120840; Mon, 23 Feb 2026 23:38:48 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c In-Reply-To: <87bjhf7z1d.fsf@HIDDEN> Message-ID: <jwvseaq932k.fsf-monnier+emacs@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> <jwvzf4z3w86.fsf-monnier+emacs@HIDDEN> <87bjhf7z1d.fsf@HIDDEN> Date: Mon, 23 Feb 2026 23:38:47 -0500 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.217 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: -1.3 (-) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, Eli Zaretskii <eliz@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: -2.3 (--) > What do you think of simplifying it like this? The "real" idle timer is > an entry on timer-idle-list. When we enter an idle period, each idle > timer creates for itself an internal non-idle regular timer that runs > the user-specified idle timer function. This internal regular timer > works like any other regular timer with respect to initial delays and > repetition. When we exit an idle period, we cancel each idle timer's > internal timer, but leave the idle timer itself (the entry on > timer-idle-list) alive, and on entry to the next idle period, we have it > create a new regular timer for that idle period. Sounds good to me. That would move idle timers out of the C code. Instead the C code would have to provide a "idle start hook" as well as an "idle end hook". While at it, it might be nice to provide an "idle start time" variable (that's nil if we're not idle). An "idle end hook" might be useful for things that would otherwise use `sit-for` (e.g. `minibuffer-message` which currently uses `pre-command-hook` as poor man's "idle end hook"). > We might fix things by side effect too. For example, WDYT is the actual > intent of this code? > > (unless url-queue-progress-timer > (setq url-queue-progress-timer > (run-with-idle-timer 1 1 #'url-queue-check-progress))) The second `1` is just a deluded way to write `t`. > Intuitively, I'd expect that to mean "run this function once per second > while Emacs is idle, starting one second after Emacs becomes idle". It might have been what the coder expected but it's not what happens. To do that, you'd need to add a normal timer from the idle timer (and cancel it from the "idle end hook"). >> I find the semantics of repeated idle timers tricky (especially when you >> look at the notion of `timer--triggered`). > Yeah. That's why I hope we can find a way to define idle timers in terms > of other timers. Doing so will make the whole setup easier to understand. Maybe splitting it into two separate objects will help clarify the situation, indeed, tho it's always hard to know without actually trying. === Stefan
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.
Received: (at 80468) by debbugs.gnu.org; 24 Feb 2026 00:42:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 19:42:14 2026
Received: from localhost ([127.0.0.1]:60854 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vugVB-0003H7-VR
for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 19:42:14 -0500
Received: from dancol.org ([2600:3c01:e000:3d8::1]:57470)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1vugV8-0003Gv-Dn
for 80468 <at> debbugs.gnu.org; Mon, 23 Feb 2026 19:42:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org;
s=x;
h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From;
bh=TMHXNAUYt+WmQqpLYPIOqyMCzkqUPFwrytkmDmywnN8=; b=dizMLpm+Kd34Y4UL5NSu3EZ++P
ybJe2zR2CpormgoxtNaOvnE7MpKsG9QFtWJrROXB6FeW4WXt1aZnO+XQVrqGH0RcIbA0vWiQ6ETAd
kY5qJ/uIKgBblJjv3432VpBCJ5kn3jia30lnW0NTBi9ERquXWdviiLWRqd2uCUy0hH68W9CIBTP/u
0t8e/lrKvHdIcvX88c5YDR8V6L06bJTmJwh4Q4BqECtLZtGu7Tp55TgoAMStGLLaMVaGhodXWSE5P
MJGHKViEEsS0YaUdGfr3orb3boA6LasuuXQOAKYh4qMKMTkOrE6PVcrxjcgUOAPmgmq0TfazQwjBi
eM+OGd3w==;
Received: from [72.185.139.69] (port=59792 helo=localhost)
by dancol.org with utf8esmtpsa (TLS1.3) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2)
(envelope-from <dancol@HIDDEN>) id 1vugV5-00000000ABJ-2Uit;
Mon, 23 Feb 2026 19:42:07 -0500
From: Daniel Colascione <dancol@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c
In-Reply-To: <jwvzf4z3w86.fsf-monnier+emacs@HIDDEN>
References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN>
<jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN>
<ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN>
<jwvzf4z3w86.fsf-monnier+emacs@HIDDEN>
User-Agent: mu4e 1.14.0-pre1; emacs 31.0.50
Date: Mon, 23 Feb 2026 19:42:06 -0500
Message-ID: <87bjhf7z1d.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 80468
Cc: 80468 <at> debbugs.gnu.org, Eli Zaretskii <eliz@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 (-)
Stefan Monnier <monnier@HIDDEN> writes:
>> You could just define, I think, idle timers as timers activated in some
>> hypothetical emacs-idle-start hook and canceled again in an emacs-idle-end
>> hook. An idle timer added between the two hooks would be activated
>> immediately (and still canceled in emacs-idle-end).
>
> Yup.
>
>> You get nice predictable semantics if you define them this way, don't you?
>
> Yes, modulo the interaction with the support for repeating idle hooks
> (where you need to distinguish "internal cancels" (which cancel the
> timer only until the next idleness period) from "real cancels" (which
> cancel it "for ever")).
What do you think of simplifying it like this? The "real" idle timer is
an entry on timer-idle-list. When we enter an idle period, each idle
timer creates for itself an internal non-idle regular timer that runs
the user-specified idle timer function. This internal regular timer
works like any other regular timer with respect to initial delays and
repetition. When we exit an idle period, we cancel each idle timer's
internal timer, but leave the idle timer itself (the entry on
timer-idle-list) alive, and on entry to the next idle period, we have it
create a new regular timer for that idle period.
(We could also just reuse a regular timer, but with MPC coming along,
I'm not really worried about consing anymore.)
When the user runs cancel-timer on an idle timer, we cancel the internal
timer (if active) and then remove the idle timer from
timer-idle-list. When we activate a newly-created idle timer while we're
inside an idle period, we create the internal regular timer right away
and let it tick.
This way, we implement idle timers entirely in terms of regular timers
and free the core timer code from having to care about what an idle
timer even is. Plus, the semantics of repeated idle timers make sense:
idle timers are just regular timers that tick only while Emacs is idle.
Granted, run-with-idle-timer currently says "If REPEAT is non-nil, do
the action each time Emacs has been idle for "exactly SECS seconds (that
is, only once for each time Emacs becomes idle)", but I don't think we'd
break anything by switching to the model I described above.
We might fix things by side effect too. For example, WDYT is the actual
intent of this code?
(unless url-queue-progress-timer
(setq url-queue-progress-timer
(run-with-idle-timer 1 1 #'url-queue-check-progress)))
Intuitively, I'd expect that to mean "run this function once per second
while Emacs is idle, starting one second after Emacs becomes idle".
If we really want to exactly match the current API instead of implement
the model above, we can do that too, but the current model feels like of
silly to me.
> I find the semantics of repeated idle timers tricky (especially when you
> look at the notion of `timer--triggered`).
Yeah. That's why I hope we can find a way to define idle timers in terms
of other timers. Doing so will make the whole setup easier to understand.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 23 Feb 2026 23:08:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 18:08:37 2026 Received: from localhost ([127.0.0.1]:59764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuf2b-00051e-Cb for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 18:08:37 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39126) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vuf2Y-00051R-C2 for 80468 <at> debbugs.gnu.org; Mon, 23 Feb 2026 18:08:35 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B621710013E; Mon, 23 Feb 2026 18:08:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1771888107; bh=e+5oRO2FPdsOSO+VXeZFgfQHmUC8RF/m1RtvnSodnR4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=L9hbvB3yP3lonvsWxfW3GUblCwAN6Q8qSr71arzM+RIL0mM5MvFMETHLCpi/Phlkz cZ2ymlgAVAGjCE86SLE9auoJPHaN7OC9g9RtdS+wniOQqoG+Q7Hz+880AY8Xz6p2et D1t//ZUsIuNDQ0J0biCq0VtJSywjLKP1+MKCBk2V6rY1QvEOVDIQIqr+NgWD+Z629s /8JzYzKPtlrITIbtYDmeDBXiTbwavia4KLsSdGSezRGafpUCKUunZxVUir0S139vNR lrihtt0IuwiNt88cAgdmA2KAq0Ap3xg4tXm8qkzlchyyuOODURcAVq8ZIHTw7197r/ tlmaWsdKjjIsg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BC51310002D; Mon, 23 Feb 2026 18:08:27 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A60741206B3; Mon, 23 Feb 2026 18:08:27 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c In-Reply-To: <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> Message-ID: <jwvzf4z3w86.fsf-monnier+emacs@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> Date: Mon, 23 Feb 2026 18:08:27 -0500 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.140 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: -1.3 (-) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, Eli Zaretskii <eliz@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: -2.3 (--) > ... it's still kind of weird that the effect of scheduling a timer > enablement depends on the fine details of the context in which it's > enqueued. Would it break anything to interpret the idle timeout of N as > relative to the present if already idle? That's another option which sounds OK to me. It might break some code out there but it seems really unlikely: the usual use case is something that wants to run code "after N seconds of idle time, and then every M seconds until the end of the idle time, after which we revert to waiting for N seconds of idle time" (think of background task that first waits for 5s of idleness and then performs a bit of work every second). But in practice these are already better served (easier to write and debug) with a combination of `run-with-idle-timer` for N and `run-with-timer` for M. At least in my experience. In terms of implementation it would imply a similar amount of work as my proposal: we'd need to treat the "first" idle time differently from the subsequent ones (and the first may not be triggered because the idleness may end before we get to run the timer). > You could just define, I think, idle timers as timers activated in some > hypothetical emacs-idle-start hook and canceled again in an emacs-idle-end > hook. An idle timer added between the two hooks would be activated > immediately (and still canceled in emacs-idle-end). Yup. > You get nice predictable semantics if you define them this way, don't you? Yes, modulo the interaction with the support for repeating idle hooks (where you need to distinguish "internal cancels" (which cancel the timer only until the next idleness period) from "real cancels" (which cancel it "for ever")). I find the semantics of repeated idle timers tricky (especially when you look at the notion of `timer--triggered`). === Stefan
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 23 Feb 2026 22:49:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 17:49:00 2026 Received: from localhost ([127.0.0.1]:59529 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuejc-0003j0-9n for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 17:49:00 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:42212) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1vuejY-0003io-Lr for 80468 <at> debbugs.gnu.org; Mon, 23 Feb 2026 17:48:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=lme9RyQuusaoFHByxZt0Y+z6F0A2aFHKYawVFQilpPM=; b=dPkuz5ASihcKGZs+eQb0DamwTS bVUj2O/dn1u7np7hN6+8LJuLtwcI5QDLKYQYUjEWeYnYK6trKZrklM0A4zdiiuIeVSjoPLnW2cAvO WLgPgAKlEs4ax5cUtHg3NAgfSA9PR7JA5Bk+5ZlE1Pa3dWI2b7uC/My0/o01LSv/g46WWXxqZUk1M tDTT3ElmBUy1cMTEZlfuwKuTyZGFonTewQgKh6Y0XsUXrTkYFD+CpTRVXFWUqs5VdlAldPZ4zoVTZ g3ebGhrEca9PhvIhBtb20SvtyO0Fb6KOXuOuQ+qQ+MU+vrP3uBfvJg1BVx+rJU4gqZzzuzfzD3QpO 6Gdi4USA==; Received: from [2600:1006:b33a:f1ee:6efa:3cff:78f4:a681] (port=33552 helo=ehlo.thunderbird.net) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from <dancol@HIDDEN>) id 1vuejW-000000009oI-3d5B; Mon, 23 Feb 2026 17:48:55 -0500 Date: Mon, 23 Feb 2026 17:48:56 -0500 From: Daniel Colascione <dancol@HIDDEN> To: Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2380468=3A_Timers_cannot_enqueu?= =?US-ASCII?Q?e_timers_overly_cautious_keyboard=2Ec?= User-Agent: K-9 Mail for Android In-Reply-To: <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> Message-ID: <ED1399F5-CD03-460B-8882-697057984FA0@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 80468 Cc: 80468 <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 (-) On February 23, 2026 5:26:58 PM EST, Stefan Monnier <monnier@iro=2Eumontre= al=2Eca> wrote: >> If you or someone can find a way of doing the above without the >> downsides that the 2012 change tried to prevent, please show the code, >> and let's take this from there=2E (Personally, I don't think I >> understand how re-scanning Vtimer_list will not bring us back the bad >> problems which working on a copy was supposed to prevent, but maybe >> I'm missing something=2E) > >AFAICT the problem that commit fixed appears only for idle timers=2E > >This is because (run-with-timer TIME =2E=2E=2E) schedules the new timer t= o run >at time "now + TIME", so it's pretty obvious to the caller whether the >scheduled time is in the past or in the future=2E > >In contrast (run-with-idle-timer TIME =2E=2E=2E) schedules the timer to r= un >at "start-of-idle + TIME", which sounds like (and usually is) a relative >time in the future, but when called while idle, it is basically an >absolute time that can be in the past just as much as in the future, >much to the surprise of the caller=2E > >So maybe a good workaround for now is to refrain from calling >`copy-sequence` on the `timer-list`, i=2Ee=2E call it only for >`timer-idle-list=2E` That's a define improvement=2E Up for either that or mine, but=2E=2E=2E > >And maybe a better fix for the bug#12326 and bug#12447 is to change >`run-with-idle-timer` so it checks if the scheduled time is in the past >or the future, and if it's in the past delay the modification of >`timer-idle-list` to after the end of the current idleness=2E =2E=2E=2E it's still kind of weird that the effect of scheduling a timer e= nablement depends on the fine details of the context in which it's enqueued= =2E Would it break anything to interpret the idle timeout of N as relative = to the present if already idle? You could just define, I think, idle timers as timers activated in some hy= pothetical emacs-idle-start hook and canceled again in an emacs-idle-end ho= ok=2E An idle timer added between the two hooks would be activated immediat= ely (and still canceled in emacs-idle-end)=2E You get nice predictable semantics if you define them this way, don't you?
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 23 Feb 2026 22:27:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 17:27:07 2026 Received: from localhost ([127.0.0.1]:59339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vueOR-0002Zg-ER for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 17:27:07 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57718) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vueOP-0002Z1-Il for 80468 <at> debbugs.gnu.org; Mon, 23 Feb 2026 17:27:06 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E86FE442214; Mon, 23 Feb 2026 17:26:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1771885618; bh=bQVNIxenXNcoXi6zFerx9+ZfthnPQn83vG3aOKeY9EM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DM2Dx2qMpN1QblLgao2RiARUXa5z/NnrvkGfTxHkNEBCW3SGULCRHQSFo/4yJfUXS 2pfpaCYwee7RCXq5XOA5GP3hqCoz6r99T0go1rGFyqKKTMz4UCZmtW0s1X6UlE3+i/ OURm+PUXgZVH85hP4FBFLRtEypVXUdPG62gCeaQcfxknZlDhwWhqxByTZ8mvRmqFQ1 H8yo7JuWBagyVYyVCVGxCXEayULfzq0afdJgOEbYfZ2wnRU3XBFjv2Qqn3nQLmVnMG hCeCflCfAqcQ8tIFeKBE3GElEMSMoNus6AQI3RP5GJ57EQDI5n4jMHagggTEAjiZBB 1xToW5WxNOCWA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7F083442204; Mon, 23 Feb 2026 17:26:58 -0500 (EST) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6FC7D120CA0; Mon, 23 Feb 2026 17:26:58 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c In-Reply-To: <86ldgjbgtq.fsf@HIDDEN> Message-ID: <jwvy0kj5cxa.fsf-monnier+emacs@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> Date: Mon, 23 Feb 2026 17:26:58 -0500 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.190 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: -1.3 (-) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, Daniel Colascione <dancol@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: -2.3 (--) > If you or someone can find a way of doing the above without the > downsides that the 2012 change tried to prevent, please show the code, > and let's take this from there. (Personally, I don't think I > understand how re-scanning Vtimer_list will not bring us back the bad > problems which working on a copy was supposed to prevent, but maybe > I'm missing something.) AFAICT the problem that commit fixed appears only for idle timers. This is because (run-with-timer TIME ...) schedules the new timer to run at time "now + TIME", so it's pretty obvious to the caller whether the scheduled time is in the past or in the future. In contrast (run-with-idle-timer TIME ...) schedules the timer to run at "start-of-idle + TIME", which sounds like (and usually is) a relative time in the future, but when called while idle, it is basically an absolute time that can be in the past just as much as in the future, much to the surprise of the caller. So maybe a good workaround for now is to refrain from calling `copy-sequence` on the `timer-list`, i.e. call it only for `timer-idle-list.` And maybe a better fix for the bug#12326 and bug#12447 is to change `run-with-idle-timer` so it checks if the scheduled time is in the past or the future, and if it's in the past delay the modification of `timer-idle-list` to after the end of the current idleness. === Stefan
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.
Received: (at 80468) by debbugs.gnu.org; 23 Feb 2026 20:04:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 15:04:24 2026
Received: from localhost ([127.0.0.1]:57830 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vucAK-00014f-DB
for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 15:04:24 -0500
Received: from dancol.org ([2600:3c01:e000:3d8::1]:57818)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1vucAG-00014R-Ri
for 80468 <at> debbugs.gnu.org; Mon, 23 Feb 2026 15:04:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org;
s=x;
h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From;
bh=lqcZgvaKYs02Ma7IP+HGXF1oVbJ1z8rm9VjyHruVlY8=; b=ihiJvI+VVkJF2VtT3esbllaoEn
vpONCVEpmV+JRgg3iyyRWKmi42MBIfSP7KvFY7dTYHB7XBv8xQcRpGMKOOZd7KVdfH7+C+cR2QHWl
e/Ln/v4RdN4VbX9Dswlj6D7AsjDZX2ueTJeJyhNsrOh9+AJwhPZRE0q5cca+tYfIK65ZQ+2rmajZ/
4tAM2cUJetr980++qYyC7ezLpaFW/SaPer7LRgdjPMMiqoW75SxCPFmfGdJPjYt4TfIhDrmjNt9pP
2UvM8MwNjC9duhXD/HsPAhIHxebtlTfbsR0gbmwUtuUFViUhVbcfBjqdxgaJGXfk8EW20Rd+0Lzcg
bPZXg8uA==;
Received: from [72.185.139.69] (port=46244 helo=localhost)
by dancol.org with utf8esmtpsa (TLS1.3) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2)
(envelope-from <dancol@HIDDEN>) id 1vucAE-000000009Ju-1P2L;
Mon, 23 Feb 2026 15:04:18 -0500
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c
In-Reply-To: <86ecmbbahz.fsf@HIDDEN>
References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN>
<5eec8ae0ccdddc2e4d1dfe63ebe53d9c@HIDDEN> <86ecmbbahz.fsf@HIDDEN>
User-Agent: mu4e 1.14.0-pre1; emacs 31.0.50
Date: Mon, 23 Feb 2026 15:04:16 -0500
Message-ID: <87ldgj6xbz.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 80468
Cc: 80468 <at> debbugs.gnu.org, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
>> Date: Mon, 23 Feb 2026 12:26:08 -0500
>> From: Daniel Colascione <dancol@HIDDEN>
>> Cc: 80468 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>
>>
>> On 2026-02-23 10:49, Eli Zaretskii wrote:
>> > If you or someone can find a way of doing the above without the
>> > downsides that the 2012 change tried to prevent, please show the code,
>> > and let's take this from there. (Personally, I don't think I
>> > understand how re-scanning Vtimer_list will not bring us back the bad
>> > problems which working on a copy was supposed to prevent, but maybe
>> > I'm missing something.)
>>
>> One can DoS Emacs in numerous ways. Why is it imperative so imperative
>> to prevent this failure mode that we make it impossible to perform this
>> natural operation with timers?
>
> I presume you've read those two bugs, so you know what was the
> "failure mode" in those cases: continuous GC with high CPU usage in
> one case and a complete freeze in the other. Sounds grave enough to
> me.
Sure, but I can already make Emacs lock up any time I want with a single
sexp. :-) It's just (setf inhibit-redisplay t). I don't think we
consider this a bug, because it's a "doctor, it hurts when I do this"
situation.
I think most of the pathological timer-loops-run-forever
things are similar. What I get out of bug#12447 in particular is that
natural idioms like this
(defun foo ()
(message (format "foo %s" counter))
(setq counter (1+ counter))
(run-with-idle-timer 1 nil #'foo))
(foo)
shouldn't lock up Emacs. Can't we do something like impose a maximum
frequency (say, 1Hz) on idle timers while people let themselves do silly
things with regular timers if they really want? The policy would just be
that regardless of other considerations, no idle timer becomes ripe
until it's been at least one second since we've run another idle timer.
I'd also just move the whole timer loop to Lisp so it's easier to work
with. Not sure why timer_check_2 needs to be in C anyway. We'd also be
able to get rid of the O(N^2) recheck loop and the per-timer-check
consing at the same time. (The latter is much less an issue with our
fancy new GC, but still ugly.)
>> Setting a timer for a timer is a natural thing to want to do and
>> every other system I can think of supports doing it.
>
> I agree, but there are workarounds to get what you want even in batch
> sessions. E.g., the second timer doesn't have to be scheduled from
> the first one. So what we have is not a catastrophe, just a
> relatively minor inconvenience and perhaps a surprising behavior.
>
>> > Meanwhile, my comment is that the problem doesn't happen in
>> > interactive sessions, at least for me, probably because we have other,
>> > frequent enough, timers running which trigger timer examination
>> > frequently enough. You can therefore fix this in batch sessions as
>> > well if you add a frequent-enough do-nothing timer to the salad.
>>
>> The problem manifests in interactive sessions by extending timeouts. You
>> might set a timer for one second and, depending on things like your
>> parenthesis blink rate, that timer might fire in eight.
>
> Yes, I also thought about blinking cursor and other stuff, so I
> disabled them in an interactive session. The second timer still
> expired in 10 sec, not later. And in production sessions we routinely
> have half a dozen or more timers running at high enough frequency, not
> to mention async sub-processes etc. So in practice the problem is not
> very serious, even if you schedule a timer from another timer's
> function.
Yeah. It's surprisingly hard to get an interactive Emacs to stop waking
itself up regularly, but that's a separate matter. The problem here is
that it makes the runtimes of work scheduled via the timer mechanism
unpredictable and we don't have another way to ask Emacs to wake up and
do asynchronous work. Running "cat" as a subprocess just to force a
wakeup would be silly.
> And again, I'm not against allowing what you want to do, if that can
> be done safely. But locking up Emacs in its main loop because some
> timer did something silly is not something we can allow, because
> there's no escape from that except kill the session. We could
> tolerate that if C-g would break the vicious circle, but it doesn't.
The triple-C-g thing that came up in the quit thread from last year
could also temporarily pause timers or impose a maximum frequency, FWIW.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 23 Feb 2026 18:06:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 13:06:29 2026 Received: from localhost ([127.0.0.1]:56847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuaKC-0002D7-PQ for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 13:06:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47574) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vuaK9-0002CU-CQ for 80468 <at> debbugs.gnu.org; Mon, 23 Feb 2026 13:06:26 -0500 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 1vuaK3-00064B-W2; Mon, 23 Feb 2026 13:06:20 -0500 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=aUJrul7MCTvC3OJtZcC+MZ3wg/+IrkBdLFLBZDukLJE=; b=oWWzYqlk4xRa qeoSu5HnMrSiTjPZ2lsXnmPuUUkNKJO/MkhBy/lznMjmPALTJSaGJFP5lZbOiwAl/kCKxTaXQibSz 5p6nin4xSh4kOl0Ar8vkrQB8iHdYbZPsIYIOCZQqMRSgj1KHqxz4BMYnsGolAkk5g1yqyFy/BBr3a QMmEsB/ltH+1dB5dkrCkPWafmJA8ZGVfPuk3FNAFbOnSIOw0P8ZJ+UnR7Jiw2Oy4416ZVi4Z1fgWO OAB3zeUNuwbcFrMPu+uRfUZfXvSGTte2mhKXQNVVqHXWXb9QytMP2llbG/PMYTaj/1al8II/HPsns ywISAd34lhrCtMsgWqSSpg==; Date: Mon, 23 Feb 2026 20:06:16 +0200 Message-Id: <86ecmbbahz.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> In-Reply-To: <5eec8ae0ccdddc2e4d1dfe63ebe53d9c@HIDDEN> (message from Daniel Colascione on Mon, 23 Feb 2026 12:26:08 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> <5eec8ae0ccdddc2e4d1dfe63ebe53d9c@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, 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: -3.3 (---) > Date: Mon, 23 Feb 2026 12:26:08 -0500 > From: Daniel Colascione <dancol@HIDDEN> > Cc: 80468 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> > > On 2026-02-23 10:49, Eli Zaretskii wrote: > > If you or someone can find a way of doing the above without the > > downsides that the 2012 change tried to prevent, please show the code, > > and let's take this from there. (Personally, I don't think I > > understand how re-scanning Vtimer_list will not bring us back the bad > > problems which working on a copy was supposed to prevent, but maybe > > I'm missing something.) > > One can DoS Emacs in numerous ways. Why is it imperative so imperative > to prevent this failure mode that we make it impossible to perform this > natural operation with timers? I presume you've read those two bugs, so you know what was the "failure mode" in those cases: continuous GC with high CPU usage in one case and a complete freeze in the other. Sounds grave enough to me. > Setting a timer for a timer is a natural thing to want to do and > every other system I can think of supports doing it. I agree, but there are workarounds to get what you want even in batch sessions. E.g., the second timer doesn't have to be scheduled from the first one. So what we have is not a catastrophe, just a relatively minor inconvenience and perhaps a surprising behavior. > > Meanwhile, my comment is that the problem doesn't happen in > > interactive sessions, at least for me, probably because we have other, > > frequent enough, timers running which trigger timer examination > > frequently enough. You can therefore fix this in batch sessions as > > well if you add a frequent-enough do-nothing timer to the salad. > > The problem manifests in interactive sessions by extending timeouts. You > might set a timer for one second and, depending on things like your > parenthesis blink rate, that timer might fire in eight. Yes, I also thought about blinking cursor and other stuff, so I disabled them in an interactive session. The second timer still expired in 10 sec, not later. And in production sessions we routinely have half a dozen or more timers running at high enough frequency, not to mention async sub-processes etc. So in practice the problem is not very serious, even if you schedule a timer from another timer's function. And again, I'm not against allowing what you want to do, if that can be done safely. But locking up Emacs in its main loop because some timer did something silly is not something we can allow, because there's no escape from that except kill the session. We could tolerate that if C-g would break the vicious circle, but it doesn't. > Funny thing is, the more energy-efficient and less timer-driven you > make your Emacs, the worst this timeout extension problem gets. I'm not too happy about it, so if a safe solution can be found, I'd be glad to try it.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 23 Feb 2026 17:26:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 12:26:16 2026 Received: from localhost ([127.0.0.1]:56410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuZhH-0008BU-Px for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 12:26:16 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:54182) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1vuZhC-0008BB-RV for 80468 <at> debbugs.gnu.org; Mon, 23 Feb 2026 12:26:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:Message-ID:Subject:To:From:Date:MIME-Version; bh=rurIXZ2xPb/CBLHEKgjzj8HYva5ouzoWFiR+iAQTl3M=; b=B213fqS2NdZ5VA5LCai/NiNxbn fXqgUOB14unyG+u7qHlUK7ZFQ6l3XsRZ8micgGRUnEvZr8GQ8/REXbtdW8aDX9TlEWeZwp06o+tvb 8FQ3dPvp3rMM+6GIYHRc4QITaVpFzOEET5i+H4swJQVovQ6TfaH5RjLfmrj940m022P0rgexNkFd0 DHz2F2pEBLpJuZOENsag59qUkiMIKnxGxmSY9X31ypt3HQ0SX6GuHlTJrat2LyJA3PL/yTU2PCGMN hTr0BOrkbCGiqXw4L0Jq1YKQBVmOXJTvUWUj6hNn4MMhq5BDfjNxZFP2NdrgF+pVKLbnNk+vMmngT tVIjjq7A==; Received: from [127.0.0.1] (port=36734 helo=dancol.org) by dancol.org with esmtpa (Exim 4.98.2) (envelope-from <dancol@HIDDEN>) id 1vuZhA-000000008iw-3kBS; Mon, 23 Feb 2026 12:26:08 -0500 MIME-Version: 1.0 Date: Mon, 23 Feb 2026 12:26:08 -0500 From: Daniel Colascione <dancol@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c In-Reply-To: <86ldgjbgtq.fsf@HIDDEN> References: <877bs48n7s.fsf@HIDDEN> <86ldgjbgtq.fsf@HIDDEN> Message-ID: <5eec8ae0ccdddc2e4d1dfe63ebe53d9c@HIDDEN> X-Sender: dancol@HIDDEN Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2026-02-23 10:49, Eli Zaretskii wrote: >> From: Daniel Colascione <dancol@HIDDEN> >> Date: Sun, 22 Feb 2026 16:47:35 -0500 >> >> Consider this program: >> >> ;; -*- lexical-binding: t -*- >> ;; timer-bug.el >> (require 'cl-lib) >> (defun timer-test () >> (let ((start (float-time))) >> (cl-labels >> ((timed-msg (m) (message "@%.3f: %s" (- (float-time) start) >> m))) >> (run-at-time >> 5 nil >> (lambda () >> (timed-msg "first timer fired") >> (run-at-time >> 5 nil >> (lambda () >> (timed-msg "second timer fired"))))) >> (run-at-time >> 15 nil >> (lambda () >> (timed-msg "third timer fired") >> (throw 'done nil))) >> (timed-msg "test starting") >> (catch 'done >> (sit-for most-positive-fixnum)) >> (timed-msg "test done")))) >> >> >> Run it (to avoid complications) with >> >> emacs -Q -batch -L . -l timer-bug -f timer-test >> >> You'll see output like this: >> >> $ emacs -Q -batch -L . -l timer-bug -f timer-test >> @0.000: test starting >> @5.004: first timer fired >> @15.001: second timer fired <--------- BUG: SHOULD BE 10s >> @15.001: third timer fired >> @15.001: test done >> >> Notice that we *should* be seeing the second timer fire at the ten >> second mark, but this time doesn't actually run until the third timer >> expires. That's due to Eli's change in >> df9685f3961022245b9ab73b62023aa573862001 from 2012, which fixed #12447 >> and #12326 by having the timer code loop over a copy of the timer list >> instead of the timer list itself. This change was meant to prevent >> runaway self-enqueuing timers but had the same effect of breaking >> legitimate code like the above. >> >> timer_check should re-scan Vtimer_list and notice at least newly-added >> timers that aren't ready immediately, although honestly, I think the >> better behavior is to just re-run ripe timers and add a Lisp-level >> maximum-repeat-at-current-time circuit breaker in timer.el instead. > > If you or someone can find a way of doing the above without the > downsides that the 2012 change tried to prevent, please show the code, > and let's take this from there. (Personally, I don't think I > understand how re-scanning Vtimer_list will not bring us back the bad > problems which working on a copy was supposed to prevent, but maybe > I'm missing something.) One can DoS Emacs in numerous ways. Why is it imperative so imperative to prevent this failure mode that we make it impossible to perform this natural operation with timers? Setting a timer for a timer is a natural thing to want to do and every other system I can think of supports doing it. > Meanwhile, my comment is that the problem doesn't happen in > interactive sessions, at least for me, probably because we have other, > frequent enough, timers running which trigger timer examination > frequently enough. You can therefore fix this in batch sessions as > well if you add a frequent-enough do-nothing timer to the salad. The problem manifests in interactive sessions by extending timeouts. You might set a timer for one second and, depending on things like your parenthesis blink rate, that timer might fire in eight. Funny thing is, the more energy-efficient and less timer-driven you make your Emacs, the worst this timeout extension problem gets.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.Received: (at 80468) by debbugs.gnu.org; 23 Feb 2026 15:49:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 10:49:48 2026 Received: from localhost ([127.0.0.1]:55497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuYBw-0001rp-BG for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 10:49:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45236) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vuYBt-0001rY-Oh for 80468 <at> debbugs.gnu.org; Mon, 23 Feb 2026 10:49:46 -0500 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 1vuYBn-0001tZ-S4; Mon, 23 Feb 2026 10:49:40 -0500 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=1Thb8S3m1sxlrJb00dYYDRZHlIxQNE4FOIHhb2waRao=; b=ZqvQkcjK3ZsO xblv1NZ7OUPkepqd8TbE10Qvo2E8kM1xVqOY8+VcWE4wD/IV/eY6vwOfLriMAfKBjiev/ijAwKHzR o578rgmh8zZzBLDu2rWgnvBUzCvkFMvVfwXm37MO94e/IzGCaL8KvVrozcJXcgXP1r7vtYrG9SHj8 UEPTeg4ehIdpyOee9AoCTZDj6J5vvtVBDEPRjuDPY5DdfUwdKBdqacXi+BKtHF9CqT69LlnR2cfuf eAMsBOTBETccDN6lTjW4MF8OYrWizB5+5bY0vEjQcWVDeNhqTdvIOt3UDTXnqs9eLD5K6JMB1nTdd Ha0/ghT3pqmEkJmGMcjXhQ==; Date: Mon, 23 Feb 2026 17:49:37 +0200 Message-Id: <86ldgjbgtq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> In-Reply-To: <877bs48n7s.fsf@HIDDEN> (message from Daniel Colascione on Sun, 22 Feb 2026 16:47:35 -0500) Subject: Re: bug#80468: Timers cannot enqueue timers overly cautious keyboard.c References: <877bs48n7s.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80468 Cc: 80468 <at> debbugs.gnu.org, 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: -3.3 (---) > From: Daniel Colascione <dancol@HIDDEN> > Date: Sun, 22 Feb 2026 16:47:35 -0500 > > Consider this program: > > ;; -*- lexical-binding: t -*- > ;; timer-bug.el > (require 'cl-lib) > (defun timer-test () > (let ((start (float-time))) > (cl-labels > ((timed-msg (m) (message "@%.3f: %s" (- (float-time) start) m))) > (run-at-time > 5 nil > (lambda () > (timed-msg "first timer fired") > (run-at-time > 5 nil > (lambda () > (timed-msg "second timer fired"))))) > (run-at-time > 15 nil > (lambda () > (timed-msg "third timer fired") > (throw 'done nil))) > (timed-msg "test starting") > (catch 'done > (sit-for most-positive-fixnum)) > (timed-msg "test done")))) > > > Run it (to avoid complications) with > > emacs -Q -batch -L . -l timer-bug -f timer-test > > You'll see output like this: > > $ emacs -Q -batch -L . -l timer-bug -f timer-test > @0.000: test starting > @5.004: first timer fired > @15.001: second timer fired <--------- BUG: SHOULD BE 10s > @15.001: third timer fired > @15.001: test done > > Notice that we *should* be seeing the second timer fire at the ten > second mark, but this time doesn't actually run until the third timer > expires. That's due to Eli's change in > df9685f3961022245b9ab73b62023aa573862001 from 2012, which fixed #12447 > and #12326 by having the timer code loop over a copy of the timer list > instead of the timer list itself. This change was meant to prevent > runaway self-enqueuing timers but had the same effect of breaking > legitimate code like the above. > > timer_check should re-scan Vtimer_list and notice at least newly-added > timers that aren't ready immediately, although honestly, I think the > better behavior is to just re-run ripe timers and add a Lisp-level > maximum-repeat-at-current-time circuit breaker in timer.el instead. If you or someone can find a way of doing the above without the downsides that the 2012 change tried to prevent, please show the code, and let's take this from there. (Personally, I don't think I understand how re-scanning Vtimer_list will not bring us back the bad problems which working on a copy was supposed to prevent, but maybe I'm missing something.) Meanwhile, my comment is that the problem doesn't happen in interactive sessions, at least for me, probably because we have other, frequent enough, timers running which trigger timer examination frequently enough. You can therefore fix this in batch sessions as well if you add a frequent-enough do-nothing timer to the salad.
bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 22 Feb 2026 21:52:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 22 16:52:20 2026
Received: from localhost ([127.0.0.1]:44634 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vuHNE-0003IX-1K
for submit <at> debbugs.gnu.org; Sun, 22 Feb 2026 16:52:20 -0500
Received: from lists.gnu.org ([2001:470:142::17]:56822)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1vuHNA-0003IB-KC
for submit <at> debbugs.gnu.org; Sun, 22 Feb 2026 16:52:17 -0500
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 <dancol@HIDDEN>) id 1vuHMv-0007w7-IB
for bug-gnu-emacs@HIDDEN; Sun, 22 Feb 2026 16:52:02 -0500
Received: from dancol.org ([2600:3c01:e000:3d8::1])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <dancol@HIDDEN>) id 1vuHMs-0006M4-GO
for bug-gnu-emacs@HIDDEN; Sun, 22 Feb 2026 16:52:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org;
s=x;
h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From;
bh=3E3TUUwHX41Qtm0O9s6EAaGsf4NGTGPLRAprFJ4lUiI=; b=EELfM6yWjoB+pQDtNTD2TCDhK/
i2AQcn6rbIbDaXHPg+iUxJjqBectxtcErebtwoUtRDg6VTHEwJrNTeC8WG8fdnzyWJ6WAlEosB101
BrSfhmebkcy/2wPf+9NcaSUQ29swNUoPRFD/3628bAYs83uK/8nlqPY7sh0/ae20dxsgRiJkSTktA
nd1e2B6i0PQjzFDL3bPsb7XsUeVcAAoKQfYa1XxV58mv96S+M97R/EV8l0AdEtx92uekcmqUh1TA9
DT4YHnRuBremugji9Sx1iONk+5inb3LwawXw5nsXCFvh3Oi+5t1OfwzFDnppziOJGAebYtQy8s8jx
27KCk2TA==;
Received: from [72.185.139.69] (port=34986 helo=localhost)
by dancol.org with utf8esmtpsa (TLS1.3) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2)
(envelope-from <dancol@HIDDEN>) id 1vuHIe-000000001DS-16p3
for bug-gnu-emacs@HIDDEN; Sun, 22 Feb 2026 16:47:36 -0500
From: Daniel Colascione <dancol@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: Timers cannot enqueue timers overly cautious keyboard.c
User-Agent: mu4e 1.14.0-pre1; emacs 31.0.50
Date: Sun, 22 Feb 2026 16:47:35 -0500
Message-ID: <877bs48n7s.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2600:3c01:e000:3d8::1;
envelope-from=dancol@HIDDEN; helo=dancol.org
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
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: -0.1 (/)
Consider this program:
;; -*- lexical-binding: t -*-
;; timer-bug.el
(require 'cl-lib)
(defun timer-test ()
(let ((start (float-time)))
(cl-labels
((timed-msg (m) (message "@%.3f: %s" (- (float-time) start) m)))
(run-at-time
5 nil
(lambda ()
(timed-msg "first timer fired")
(run-at-time
5 nil
(lambda ()
(timed-msg "second timer fired")))))
(run-at-time
15 nil
(lambda ()
(timed-msg "third timer fired")
(throw 'done nil)))
(timed-msg "test starting")
(catch 'done
(sit-for most-positive-fixnum))
(timed-msg "test done"))))
Run it (to avoid complications) with
emacs -Q -batch -L . -l timer-bug -f timer-test
You'll see output like this:
$ emacs -Q -batch -L . -l timer-bug -f timer-test
@0.000: test starting
@5.004: first timer fired
@15.001: second timer fired <--------- BUG: SHOULD BE 10s
@15.001: third timer fired
@15.001: test done
Notice that we *should* be seeing the second timer fire at the ten
second mark, but this time doesn't actually run until the third timer
expires. That's due to Eli's change in
df9685f3961022245b9ab73b62023aa573862001 from 2012, which fixed #12447
and #12326 by having the timer code loop over a copy of the timer list
instead of the timer list itself. This change was meant to prevent
runaway self-enqueuing timers but had the same effect of breaking
legitimate code like the above.
timer_check should re-scan Vtimer_list and notice at least newly-added
timers that aren't ready immediately, although honestly, I think the
better behavior is to just re-run ripe timers and add a Lisp-level
maximum-repeat-at-current-time circuit breaker in timer.el instead.
Daniel Colascione <dancol@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#80468; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.