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

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

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Thu, 02 Dec 2021 00:08:37 +0100
> 
> My idea to per-use it is to simply run 'update-hooks' on clock beat, so any
> application can register a hook that will be called on a "clock beat". While it
> is maybe not so super-synchronized with system clock, it still gives impression
> of clocks in Emacs be synchronized.

Isn't that what timers are for?  Why can't you use run-with-timer for
what you want to do?

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

[Lars Ingebrigtsen]

Arthur Miller <arthur.miller@live.com> writes:

> My idea to per-use it is to simply run 'update-hooks' on clock beat,
> so any application can register a hook that will be called on a "clock
> beat". While it is maybe not so super-synchronized with system clock,
> it still gives impression of clocks in Emacs be synchronized.

If I understand correctly, by "clock beat" you mean an integer multiple
of some time?  timer.el didn't support that well previously, but this
was fixed a few months ago (in 50765f3f) with TIME:

- or t (with non-nil REPEAT) meaning the next integral
  multiple of REPEAT.

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

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

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Thu, 02 Dec 2021 00:08:37 +0100
>> 
>> My idea to per-use it is to simply run 'update-hooks' on clock beat, so any
>> application can register a hook that will be called on a "clock beat". While it
>> is maybe not so super-synchronized with system clock, it still gives impression
>> of clocks in Emacs be synchronized.
>
> Isn't that what timers are for?  Why can't you use run-with-timer for
> what you want to do?

Becaue it does not syncrhonize with clock that Emacs displays, if it displays. I
could use a timer, and I used it as mentioned in the description of suggestion.

As mentioned, not pretty, if different application will like to be notifed
at "11:30" clock time, and then one happends like half minut before the other.

Also there is no reason to create one timer per each application if all
application is want to be notified when certain clock time occur. It saves code
repetion that each application has to setup. Further, if user is displaying time
on the modeline, and those variables are all calculated, why should other
application re-define and re-calculate them.

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

[Arthur Miller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> My idea to per-use it is to simply run 'update-hooks' on clock beat,
>> so any application can register a hook that will be called on a "clock
>> beat". While it is maybe not so super-synchronized with system clock,
>> it still gives impression of clocks in Emacs be synchronized.
>
> 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.

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.

> was fixed a few months ago (in 50765f3f) with TIME:
>
> - or t (with non-nil REPEAT) meaning the next integral
>   multiple of REPEAT.

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

[Lars Ingebrigtsen]

Arthur Miller <arthur.miller@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

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

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: 52235@debbugs.gnu.org
> Date: Thu, 02 Dec 2021 10:19:37 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Isn't that what timers are for?  Why can't you use run-with-timer for
> > what you want to do?
> 
> Becaue it does not syncrhonize with clock that Emacs displays, if it
> displays.

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?

> As mentioned, not pretty, if different application will like to be notifed
> at "11:30" clock time, and then one happends like half minut before the other.

Emacs cannot guarantee that the notification will happen exactly at
the requested time anyway.  This limitation is in effect both for
display-time-mode and for timers, and for exactly the same reasons.

> Also there is no reason to create one timer per each application if all
> application is want to be notified when certain clock time occur.

So create a single timer that applications could register to.

> Further, if user is displaying time
> on the modeline, and those variables are all calculated, why should other
> application re-define and re-calculate them.

Because the way users customize time display on the mode line doesn't
necessarily fits the needs of an arbitrary other application which
wants to be notified at some time.  For example, users can control the
frequency and the resolution of the time display, and their
preferences for that can be correct for some other application only by
sheer luck.

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.

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

[Arthur Miller]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Arthur Miller <arthur.miller@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").

Ok. I have tried it now; it seems to work :). TBH I didn't realize what "integer
multiple of REPEAT" means in this aspect, so I didn't even use 't option, and I
also wanted it to start immidiately so I thought I wanted 'nil = meaning now
option. I don't know, blame it on my english, but I found that one tricky to
understand doc.

I don't know if I can suggest better wording myself, but maybe it might help
someone else one day, if that last option was reworded somehow. I think people
usually use term "wall clcok" in this context, but I am not sure, I am not
native english speaker, but I think I have encountered that term in std c++ docs
and Java docs.

>> 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.

I guess timers are not very expensive resource in a system, no idea actually how
memory/cpu costly (or cheaply) they are, but it is just that I have to
keep track of it to cancel it when I am done to not leak resource.

By now I am also used to "hooks" in Emacs, and Emacs acting as a framework in
many cases, so it kind of suits my mental build better to add a function to a
hook and get it called than have to setup this manually.

Anyway, this was a suggestion and thanks for the clarification about integer
multiple in this context :-).

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

[Arthur Miller]

Eli Zaretskii <eliz@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.

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 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").

Do you mean this part?

    - or t (with non-nil REPEAT) meaning the next integral
      multiple of REPEAT.

Shouldn't that be "integer" multiple?  From searching online it seems
like you can use them interchangeably in math (I think?), but presumably
most of us here are more programmers than mathematicians and so might
prefer the more mundane word here.

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

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 2 Dec 2021 16:52:16 -0800
> Cc: Arthur Miller <arthur.miller@live.com>, 52235@debbugs.gnu.org
> 
>     - or t (with non-nil REPEAT) meaning the next integral
>       multiple of REPEAT.
> 
> Shouldn't that be "integer" multiple?

No, "integral" is correct here.  "Integer multiple" is actually a
subtle mistake.

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

[Lars Ingebrigtsen]

Arthur Miller <arthur.miller@live.com> writes:

> Ok. I have tried it now; it seems to work :). TBH I didn't realize
> what "integer multiple of REPEAT" means in this aspect, so I didn't
> even use 't option, and I also wanted it to start immidiately so I
> thought I wanted 'nil = meaning now option. I don't know, blame it on
> my english, but I found that one tricky to understand doc.

Yes, the documentation is rather gnomic here.  I've now expanded this
bit in both the doc string and the manual so that it should be easier to
understand.

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