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

Previous Next

Full log

Message #29 received at 52235 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 52235 <at> debbugs.gnu.org
Subject: Re: bug#52235: 29.0.50; Suggestion: refactor time.el into a more
 general 'clock' framework
Date: Fri, 03 Dec 2021 00:48:05 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Because it doesn't synchronize with clock... what happens?
>
> And what do you mean by "doesn't synchronize with clock that Emacs
> displays"?  The time comes from the same source, so how can it be not
> synchronized? in what sense?

Lars clarified about that. What I meant was what "wall clock" usually mean in
this context; I didn't understand that "integer multiple of REPEAT" (as in docs)
meant actually that.

> My point is that I don't see why this feature has to touch
> display-time-mode.  That is not clean, IMO.  It should be a separate
> feature that uses timers.  The feature could create a timer the first
> time it is requested, and then any additional clients could reuse the
> same timer.  Of course, if you want to use a single timer, you'd still
> need to solve the potentially different needs of each application: for
> example, one of them may wish to be notified each second, the other
> each hour.
Indeed, you are correct about that one. I am a bit used to Emacs "hook"
frameworking, so I just wanted to have a hook to add somewhere and get my clock
going :).

But yes, you are right, one clock might wish to display seconds while
another one only minutes.

Previous Next

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