Persistent clocks

Persistent clocks

[Denis Bueno]

Hi all,

I'm a reticent poster, but long time subscriber, of this mailing list.
 Recently I've started using org-mode more seriously, and for various
reasons which are not important, I find the current clock
implementation of limited usefulness.  Basically, I may restart Emacs
multiple times each day, and what I'm wondering is whether persistent
clocks would be easy or even useful to implement.  If it's easier to
change my habits than org-mode, I'm open to that.

The behavior I'm thinking seems simple:
  - keep the clock information in drawers (as it already seems to be)
  - when a new org-mode file is opened and there's no clock running,
scan the file for any unfinished clocks.  If there is one, restart a
clock from the appropriate start time.  If there is more than one,
signal an error.

That implementation wouldn't require serialising the clock state to a
different location --- just restarting the clock that was active when
Emacs was killed.

Does this idea make sense, and would it be useful to anyone?  Or
should I think about adapting my workflow to pay attention to the
clock more?

-- 
 Denis

Re: Persistent clocks

[Bernt Hansen]

"Denis Bueno" <dbueno@gmail.com> writes:

> I'm a reticent poster, but long time subscriber, of this mailing list.
>  Recently I've started using org-mode more seriously, and for various
> reasons which are not important, I find the current clock
> implementation of limited usefulness.  Basically, I may restart Emacs
> multiple times each day, and what I'm wondering is whether persistent
> clocks would be easy or even useful to implement.  If it's easier to
> change my habits than org-mode, I'm open to that.
>
> The behavior I'm thinking seems simple:
>   - keep the clock information in drawers (as it already seems to be)
>   - when a new org-mode file is opened and there's no clock running,
> scan the file for any unfinished clocks.  If there is one, restart a
> clock from the appropriate start time.  If there is more than one,
> signal an error.
>
> That implementation wouldn't require serialising the clock state to a
> different location --- just restarting the clock that was active when
> Emacs was killed.
>
> Does this idea make sense, and would it be useful to anyone?  Or
> should I think about adapting my workflow to pay attention to the
> clock more?

I use the clock all the time and occasionally I restart Emacs during
the day.  In that case I find it pretty easy to go to agenda view for
today, hit 'l' to show the clocked time for today and pick the last item
and clock that in again - then I just delete the new clock line and the
old start time is used when the clock stops.

I personally don't do this enough to want it to be automatic.  In other
work flows it may be wrong for it to be automatic.  For example: If you
are in org FILE1 and quit with an open clock and then restart Emacs and
open org FILE2 which also has an open clock it would be wrong to make
that one active - since the last clocked time you used was in FILE1.

Since Carsten added the start and end times recently to the agenda view
for log-mode it's easy to see which clock entries are missing an end
time.

My vote would be just to manually restart the clock using the agenda as
described above.

Just my 2 cents,

-Bernt

Re: Persistent clocks

[Denis Bueno]

On Tue, Jul 29, 2008 at 21:26, Bernt Hansen <bernt@norang.ca> wrote:
> I use the clock all the time and occasionally I restart Emacs during
> the day.  In that case I find it pretty easy to go to agenda view for
> today, hit 'l' to show the clocked time for today and pick the last item
> and clock that in again - then I just delete the new clock line and the
> old start time is used when the clock stops.

Ah, I see.  I just tried it.  Thanks for the tip.

> I personally don't do this enough to want it to be automatic.  In other
> work flows it may be wrong for it to be automatic.  For example: If you
> are in org FILE1 and quit with an open clock and then restart Emacs and
> open org FILE2 which also has an open clock it would be wrong to make
> that one active - since the last clocked time you used was in FILE1.

I agree, there are thorny issues.  I think your way is better,
especially considering that I'm not _constantly_ restarting Emacs, I
just want to be able to _deal_ with restarting Emacs.

Thanks.

--
 Denis

Re: Re: Persistent clocks

[Jason F. McBrayer]

"Denis Bueno" <dbueno@gmail.com> writes:

> On Tue, Jul 29, 2008 at 21:26, Bernt Hansen <bernt@norang.ca> wrote:
>> I use the clock all the time and occasionally I restart Emacs during
>> the day.  In that case I find it pretty easy to go to agenda view for
>> today, hit 'l' to show the clocked time for today and pick the last item
>> and clock that in again - then I just delete the new clock line and the
>> old start time is used when the clock stops.
>
> Ah, I see.  I just tried it.  Thanks for the tip.
>
>> I personally don't do this enough to want it to be automatic.  In other
>> work flows it may be wrong for it to be automatic.  For example: If you
>> are in org FILE1 and quit with an open clock and then restart Emacs and
>> open org FILE2 which also has an open clock it would be wrong to make
>> that one active - since the last clocked time you used was in FILE1.
>
> I agree, there are thorny issues.  I think your way is better,
> especially considering that I'm not _constantly_ restarting Emacs, I
> just want to be able to _deal_ with restarting Emacs.

It might be nice if C-u C-c C-x C-i could find open clocks in the open
file and in the agenda files, and offer them to you as things to clock
into.  Perhaps only if it can't find any recently-clocked tasks in the
normal way, which it can't do right after starting emacs.  It's pretty
rare for me to restart emacs in the middle of the workday, but when I do
(usually because of upgrading emacs or a major package), the
agenda-log-view shuffle /works/ (better than manually searching), but
could be better.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray@carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |