GNU bug report logs - #52235
29.0.50; Suggestion: refactor time.el into a more general 'clock' framework

Previous Next

Package: emacs;

Reported by: Arthur Miller <arthur.miller <at> live.com>

Date: Thu, 2 Dec 2021 01:35:02 UTC

Severity: normal

Found in version 29.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: 52235 <at> debbugs.gnu.org
Subject: bug#52235: 29.0.50; Suggestion: refactor time.el into a more general 'clock' framework
Date: Thu, 02 Dec 2021 10:55:20 +0100
Arthur Miller <arthur.miller <at> live.com> writes:

>> If I understand correctly, by "clock beat" you mean an integer multiple
>> of some time?
> I am not sure if we speak about same thing; but I mean the clock, synchronized
> with what Emacs shows as time.

I'm not sure either, because I'm not sure what you mean by
"synchronized".  But if you want a timer to run at 11:01:00, 11:02:00,
11:03:00, then timer.el has support for that (and calls that "integer
multiple").

> Also there is no read to run several timers when one timer could
> be fine to run several hooks as well as saving some code repetition.

Running several timers is fine.  And I don't think there's any code
repetition?  Just say

(run-at-time t 60 (lambda () (message (format-time-string "%H:%M:%S"))))

or whatever you want.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




This bug report was last modified 3 years and 263 days ago.

Previous Next


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