From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nljlistbox2@gmail.com (N. Jackson) Newsgroups: gmane.emacs.bugs Subject: bug#23929: 25.0.95; Doc of run-at-time doesn't describe behaviour if system was sleeping at time Date: Sat, 09 Jul 2016 15:57:49 -0300 Message-ID: <87poqm7i6q.fsf@moondust.awandering> References: <878txaj0bh.fsf@moondust.awandering> <83y45ag388.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1468090768 9120 80.91.229.3 (9 Jul 2016 18:59:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Jul 2016 18:59:28 +0000 (UTC) Cc: 23929@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 09 20:59:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bLxT8-0007xU-N7 for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2016 20:59:14 +0200 Original-Received: from localhost ([::1]:52144 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLxT7-0008NB-Uu for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2016 14:59:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLxT0-0008N5-C6 for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2016 14:59:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLxSw-0002nx-41 for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2016 14:59:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLxSw-0002nt-1P for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2016 14:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bLxSv-0005ms-NS for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2016 14:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: nljlistbox2@gmail.com (N. Jackson) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Jul 2016 18:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23929-submit@debbugs.gnu.org id=B23929.146809068522164 (code B ref 23929); Sat, 09 Jul 2016 18:59:01 +0000 Original-Received: (at 23929) by debbugs.gnu.org; 9 Jul 2016 18:58:05 +0000 Original-Received: from localhost ([127.0.0.1]:44383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLxS0-0005lQ-Nn for submit@debbugs.gnu.org; Sat, 09 Jul 2016 14:58:04 -0400 Original-Received: from mail-io0-f172.google.com ([209.85.223.172]:35854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLxRy-0005kw-MG for 23929@debbugs.gnu.org; Sat, 09 Jul 2016 14:58:02 -0400 Original-Received: by mail-io0-f172.google.com with SMTP id s93so27271226ioi.3 for <23929@debbugs.gnu.org>; Sat, 09 Jul 2016 11:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=X8Rq20ECvtU4qLxSLm6l24dY6ui9QJ+kVzubjSzP72c=; b=0fYyJNdePlJyi8QCYuToKGRTL0bqQBh7awCdWBRpJFnaqBtVxs8eGs7UI9qeMubo71 9QHFAKPbf3SEThWMbhYRk8sbCnsdMBHUntRMxs2AfwsZJrGh+KSD8wfWwjoM5W+ZXF8U WD5yiUK+2DRVTWtJcAdWLmbGAVppUS4KMBMnBwd07aMAvHSvXYYYu1N8Q7WzGEbnmwhv fe/2kBZb+VTtb5chVHOGCDBpTbL5yWCwWBG9xFTV2LmVjFj//QNl658l/BGA1eN2BBR9 jsQmTyudWOsUjtcxxWXTfUVjvOGZ1JF09YgxO8UZaoijCkGbK0sAWbV2FiHl+nuqiR8r cNng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=X8Rq20ECvtU4qLxSLm6l24dY6ui9QJ+kVzubjSzP72c=; b=CbXsnhNz/lcnoGzxdJAELMdeqNNTr4E8Vi7QVjG86HT6OPbL5BHh0Yhr57ZWEi5QXC bAV074NbraBTbXWrejBKCeDgljLDa5BwBqdlNCFNnysbJxmXeZXFdrGy2d2TuEcCNEGt 0aRdWYlVtV3CjurSl301dJX4Lm8SDboS4iVArmvEnu7e+rZVWEMWBRmk4b1dyglHZmB9 qHh/X/wRMA6p/h/odr/nEnej1xhwqgbOoU7zddHCrXfk9CcCnUhBaeR964imPpjecKKe RFxUFxvA8Wyda0//5R6Rgp8me6J95vD2+dYkX9KLDue+4P5S7AKGDAm1OKskbjEHFeme yI2g== X-Gm-Message-State: ALyK8tIhU3d5TZ23j1ngwCKyLyCF2LB50dEheutA2ai90EyCB1+n4HuhqEZxOjoRsYqr7Q== X-Received: by 10.107.202.198 with SMTP id a189mr13983647iog.164.1468090677053; Sat, 09 Jul 2016 11:57:57 -0700 (PDT) Original-Received: from moondust.nodomain.none ([142.227.16.2]) by smtp.gmail.com with ESMTPSA id 80sm112668iof.18.2016.07.09.11.57.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 09 Jul 2016 11:57:56 -0700 (PDT) In-Reply-To: <83y45ag388.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Jul 2016 19:56:07 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:120713 Archived-At: At 19:56 +0300 on Saturday 2016-07-09, Eli Zaretskii wrote: >> From: nljlistbox2@gmail.com (N. Jackson) >> Date: Sat, 09 Jul 2016 12:30:42 -0300 >>=20 >> The documentation of run-at-time -- the doc string and (info "(elisp) >> Timers") -- does not say what happens if the system was sleeping when >> the timer would have run. > > It also doesn't say what happens if Emacs didn't get any CPU time when > the timer would have run -- which is a more general description of the > situation you mention. > > If instead > > Perform an action at time TIME. > > we say > > Perform an action at or after time TIME. > > will this take care of the issue you are raising? Yes, I think it might take care of the issue. On the other hand, perhaps it would be worth being slightly more explicit in the documentation in the manual? Perhaps it would be worth mentioning the general case of Emacs not getting any CPU time when the timer would have run, as well as the specific case of the system being suspended / sleeping. I'm not in a good position to judge how much insight into system internals the reader of the elisp manual is expected to have. To me, at least, it isn't immediately obvious that the case of the system being suspended when the timer would have run is the "same" as the case of the system being busy elsewhere when the timer would have run. As a casual user of the function, I just want to know whether, if I have a timer set to run at 6:00 AM but I don't wake up my system until 8:00 AM, if my timer will run once my system has woken up, or if the timer will be skipped until the next day (provided my system is awake at 6:00 AM the next day). I would be more reassured if I saw text along the following lines in the manual entry (provided it is true): "If Emacs didn't get any CPU time when the timer would have run (for example if the system was busy running another process or if the computer was sleeping or in a suspended state), the timer will run (late) as soon as Emacs resumes and is idle." Of course, this is already almost, but not quite, stated already twice in the manual entry. Firstly in the second paragraph: "Emacs cannot run timers at any arbitrary point in a Lisp program; it can run them only when Emacs could accept output from a subprocess: namely, while waiting or inside certain primitive functions such as =E2=80=98sit-for=E2=80=99 or =E2=80=98read-= event=E2=80=99 which _can_ wait. Therefore, a timer=E2=80=99s execution may be delayed if Emacs is busy. However, the time of execution is very precise if Emacs is idle." But this only covers the case of Emacs being busy when the timer would have run. And later: "A repeating timer nominally ought to run every REPEAT seconds, but remember that any invocation of a timer can be late. Lateness of one repetition has no effect on the scheduled time of the next repetition. For instance, if Emacs is busy computing for long enough to cover three scheduled repetitions of the timer, and then starts to wait, it will immediately call the timer function three times in immediate succession (presuming no other timers trigger before or between them)." But this only covers the case of repeating timers.