From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.bugs Subject: bug#75361: SOLVED - Re: bug#75361: 31.0.50; run-with-idle-timer not working unless there is some activity Date: Mon, 6 Jan 2025 15:47:36 -0500 Message-ID: References: <87r05jpm38.fsf@gnu.support> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000982677062b0fc1f3" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3392"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75361@debbugs.gnu.org To: Jean Louis Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 06 21:49:18 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tUu2I-0000i9-GZ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Jan 2025 21:49:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUu25-0001pa-Um; Mon, 06 Jan 2025 15:49:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUu24-0001pM-6r for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 15:49:04 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tUu23-0007xT-Sb for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 15:49:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=jH3lrSKgLR0G3I8daSK2xq0d5zziUQTgcXA+YaycWVA=; b=FldLQflukcFSZ3giRjMEADv8BJnsYOxbuNvkrmRT1Kguw3p2iaUochZfG/Ki6B8V278rRC134pxZmTnYgBcXygoJBK8nWRh86VZftXPmA7P4JeslW96zPxceH4KndAkLDHas0r9A/ZcSr9vknYy4zBB7aX2VdB/v4nNYaCDqhnmGsKF/y0F1BW3GlMYZ/0yrAxBgOuJRTYJAOKiCXdEeIvhsmds1I5SUXn1n0K1u+kMuKqaDLbjsHa5xRDnqV1aR62NPiFvvm+z8c6Uz1d38762YTX9m25v64yb0nhER7OxLONNQZwAddXb82HWU82NsNURAmtjzuamggOTb6aJLKA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUu22-0002Co-DF for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2025 15:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ship Mints Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Jan 2025 20:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75361 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 75361-submit@debbugs.gnu.org id=B75361.17361965418472 (code B ref 75361); Mon, 06 Jan 2025 20:49:02 +0000 Original-Received: (at 75361) by debbugs.gnu.org; 6 Jan 2025 20:49:01 +0000 Original-Received: from localhost ([127.0.0.1]:40412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUu20-0002CU-Vu for submit@debbugs.gnu.org; Mon, 06 Jan 2025 15:49:01 -0500 Original-Received: from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c]:59805) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tUu1y-0002CE-Nd for 75361@debbugs.gnu.org; Mon, 06 Jan 2025 15:49:00 -0500 Original-Received: by mail-vs1-xe2c.google.com with SMTP id ada2fe7eead31-4afe99e5229so4179226137.3 for <75361@debbugs.gnu.org>; Mon, 06 Jan 2025 12:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736196533; x=1736801333; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jH3lrSKgLR0G3I8daSK2xq0d5zziUQTgcXA+YaycWVA=; b=DDqVzP22dsXhFR/+9Ts/CojtPwa9/Wt77yuiIIKO4/yZxoZnClH/W8iYQAE0Mn9sCv VhAh3qZGMmoaBDoRXA2vjQ2nOdJ0z7pVBc+rEoMf2EEjlHb5jCpzXz+r3Xz714n0PamM K+1fcQdlJFu+5fZHXtYZCzvb+tCTQkRQIKPBnZRL6MpC3PltvwlZp36n6dwTRoTP1i9U 8l8v5AcVGZ2SX5ZkwoCuX1rkoFxWaJfZl09Tv0gjTsRW3um6CUPe6sBj64AfqzO7N2pB UYJLpZOeu4xybp7KiPjDjChEgcR/gxWwGN24Wb+AmoRltX47Z4eug5xt0QKFcodOuVXr 8AYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736196533; x=1736801333; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jH3lrSKgLR0G3I8daSK2xq0d5zziUQTgcXA+YaycWVA=; b=j/aICu8zvBnn9B/YaVPTDbv9Hk37EgHzeAj8iVhU+UK84s1wWSKmBPUUYGWGIrTFgM REBbpIYk6UHwu8NfpUniYrR6cZUjbqMkt2cIjz+Yue5c7lII0rhGpQnLUNVkSMYkHzwV PQBucEte5vqx15PlRHj5ExF3/lq9JIzTaPE1AWghldOaWSrd8U0wPE5WnXLRAeBM25x8 sbpBj8CY1pM2RUkDBBTMOMEBsWW3bGkRGvnnrd4miUb3vjsr6VAnOSWVW/vaauAeJHTx 94zrFgzSjtm6yI0ScvG8bwrOYIQtw/ChXIkTN5CFMyMGsL0PGQ2trcypdcLOGoj8Ten3 KgbA== X-Gm-Message-State: AOJu0YzpD7ybDUsywwCv0sQC5fq81u3XDosPzVRpWh/qSh6fcLNdQTrp +krfMUUCbR/ziiyPr2bbB1kw3d+PbeqbRMTIsMFjGTvKluhkMNuwk0xje77gxvwJMuRnE6cqfMy xZq0tJPLOTFbkgu+MaUznJlhfXV0= X-Gm-Gg: ASbGnctXzplNCZbRcw3G/+eVBYWr6WokhZ5QLepaR8TzQeNCb2X+aLIBsuUTjdwcHn2 8kXn1ov1nJC4nmy/AlsxiBzc4nLEPqUNinLLYIg== X-Google-Smtp-Source: AGHT+IEtauGRd0NcOGzH/dpepHQovyopRqnlzXKmS5f2vArXIBCii1lJw/BpM8m6XQeH6T3+CFtSOj7rERI9p2G8LKQ= X-Received: by 2002:a05:6102:32d4:b0:4b1:24c0:4274 with SMTP id ada2fe7eead31-4b2cc494ed0mr46084177137.26.1736196532737; Mon, 06 Jan 2025 12:48:52 -0800 (PST) In-Reply-To: X-Gm-Features: AbW1kvbDNve42mMJruRxcW9MMXS_27pNTq7jA7OjxA7e28Dq9iVtpKa7Ck1sUY4 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298703 Archived-At: --000000000000982677062b0fc1f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also in the documentation for idle timers, you can find a different approach that might work for you than the one you proposed. At the very least, your timer will fire only when Emacs is idle rather than polling for idleness. HTH. https://www.gnu.org/software/emacs/manual/html_node/elisp/Idle-Timers.html "Similarly, do not write an idle timer function that sets up another idle timer (including the same idle timer) with secs argument less than or equal to the current idleness time. Such a timer will run almost immediately, and continue running again and again, instead of waiting for the next time Emacs becomes idle. The correct approach is to reschedule with an appropriate increment of the current value of the idleness time, as described below." -Stephane On Mon, Jan 6, 2025 at 3:30=E2=80=AFPM Jean Louis wrote: > * Ship Mints [2025-01-04 20:58]: > > I believe this is intended behavior. You should use a regular interval > > timer if you want repeating executions that do not depend upon Emacs > > entering the idle state. Not sure why you think this worked differently > in > > the recent past. > > > > "Emacs becomes *idle* when it starts waiting for user input (unless it > > waits for input with a timeout, see Reading One Event > > < > https://www.gnu.org/software/emacs/manual/html_node/elisp/Reading-One-Eve= nt.html > >), > > and it remains idle until the user provides some input. If a timer is s= et > > for five seconds of idleness, it runs approximately five seconds after > > Emacs first becomes idle. Even if repeat is non-nil, this timer will no= t > > run again as long as Emacs remains idle, because the duration of idlene= ss > > will continue to increase and will not go down to five seconds again." > > Okay I got it. Though I am surprised as I was using idle timer > thousands of times. I was thinking it repeated itself, while it > didn't. > > Recently I started observing and have seen it is getting blocked, I > wondered why, due to lack of understanding. > > I have found solution to my problem, so I will simply run the function > `run-with-timer` and then check if user is idle to execute it. > > Basically, I do not need executions if user is not idle. > > (defun my-hello () > (when (and (current-idle-time) > (>=3D (cadr (current-idle-time)) 5)) > (rcd-message "Current idle time: %s" (cadr (current-idle-time))))) > > (run-with-timer 5 5 'my-hello) > > So in the sense of how I understand it, `run-with-idle-timer` only > sounds as the function I need, while it is not. > > I can make it this way: > > (run-with-timer 10 10 'rcd-run-repeatingly-when-idle 5 'my-hello) > > (defun rcd-run-repeatingly-when-idle (secs function &rest args) > (when (and (current-idle-time) > (>=3D (cadr (current-idle-time)) secs)) > (apply 'funcall function args))) > > As that way it will use `run-with-timer` though only when user is idle > for SECS. > > -- > Jean Louis > > > > --000000000000982677062b0fc1f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also in the documentation for idle timers, you can find a different appr= oach that might work for you than the one you proposed. At the very least, = your timer will fire only when Emacs is idle rather than polling for idlene= ss. HTH.
=

&= quot;Simi= larly, do not write an idle timer function that sets up another idle timer = (including the same idle timer) with=C2=A0secs=C2=A0argument = less than or equal to the current idleness time. Such a timer will run almo= st immediately, and continue running again and again, instead of waiting fo= r the next time Emacs becomes idle. The correct approach is to reschedule w= ith an appropriate increment of the current value of the idleness time, as = described below."

-Stephane

On Mon, Jan 6, 2025 at = 3:30=E2=80=AFPM Jean Louis <bugs@gnu.support> wrote:
* Ship Mints <shipmints@gmail.com> [2025= -01-04 20:58]:
> I believe this is intended behavior. You should use a regular interval=
> timer if you want repeating executions that do not depend upon Emacs > entering the idle state. Not sure why you think this worked differentl= y in
> the recent past.
>
> "Emacs becomes *idle* when it starts waiting for user input (unle= ss it
> waits for input with a timeout, see Reading One Event
> <https://www= .gnu.org/software/emacs/manual/html_node/elisp/Reading-One-Event.html&g= t;),
> 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 n= ot
> run again as long as Emacs remains idle, because the duration of idlen= ess
> will continue to increase and will not go down to five seconds again.&= quot;

Okay I got it. Though I am surprised as I was using idle timer
thousands of times. I was thinking it repeated itself, while it
didn't.

Recently I started observing and have seen it is getting blocked, I
wondered why, due to lack of understanding.

I have found solution to my problem, so I will simply run the function
`run-with-timer` and then check if user is idle to execute it.

Basically, I do not need executions if user is not idle.

(defun my-hello ()
=C2=A0 (when (and (current-idle-time)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(>=3D (cadr (current-idl= e-time)) 5))
=C2=A0 =C2=A0 (rcd-message "Current idle time: %s" (cadr (current= -idle-time)))))

(run-with-timer 5 5 'my-hello)

So in the sense of how I understand it, `run-with-idle-timer` only
sounds as the function I need, while it is not.

I can make it this way:

(run-with-timer 10 10 'rcd-run-repeatingly-when-idle 5 'my-hello)
(defun rcd-run-repeatingly-when-idle (secs function &rest args)
=C2=A0 =C2=A0 (when (and (current-idle-time)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(>=3D (cadr (curr= ent-idle-time)) secs))
=C2=A0 =C2=A0 =C2=A0 (apply 'funcall function args)))

As that way it will use `run-with-timer` though only when user is idle
for SECS.

--
Jean Louis



--000000000000982677062b0fc1f3--