[O] Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]

[Bernt Hansen]

Giovanni Ridolfi <address@hidden> writes:

> Bernt Hansen <address@hidden> writes:
>
> Hi Bernt,
>> Giovanni Ridolfi <address@hidden> writes:
>>
>>> I think I found a bug with the option ":clock-keep"
>>>
> <snip>
>
>>> (setq org-capture-templates (quote (("t" "todo" entry (file "c:/Documents 
>>> and Settings/my-path/a.org") "* TODO %?
>>> %U
>>> %a
>>> " :immediate-finish t :clock-in t :clock-keep t))))  
> <snip>
>>>
>>> I have modified the properties in the last row:
>>>
>>> ** if :immediate-finish nil :clock-in t :clock-keep t
>                          ^^^^^ let's change it into "t"
> as in my file example.

Hi Giovanni,

I used :immediate-finish t.  I didn't notice you had 'nil' in there.

>
>>>    the clock in clocks-in
>>>    BUT the clock is not kept, it is closed anyway. 
>>
>> I can reproduce this problem.
>>
>> I think :immediate-finish never clocks in at all which is
>> why :clock-keep is not doing anything in this case.
>> I think this is a bug and the clock should probably be started and kept
>> in the new capture task.
> Actually it's a feature, not a bug.
> In my setup ":immediate-finish t" is so fast I can't even see it on my
> screen.
> manual:"When set, do not offer to edit the information[...] 
>           This makes sense if the template only needs
>           information that can be added automatically."
> So if I really want a fast, automatic template I will use :immediate
> finish t, and it doesn't have sense to clock it in. 

It never clocks in or you would end up with an 0:00 clock line by
default and it is not doing that.  You can automatically remove these
empty clock lines on clock-out by setting the variable
org-clock-out-remove-zero-time-clocks.

>
> The idea under the capture buffer is that you can clock it as along as
> you "use" it, as long as you keep it opened. So :immediate-finish nil.

I think :immediate-finish nil is identical to not including it in your
template.  It's a boolean that is either t or nil and the absence of the
boolean is the same as nil.

>
>>> ** if :immediate-finish nil :clock-in t :clock-keep t
>                          ^^^^^ let's keep the nil option
>>>    the clock in clocks-in
>>>    BUT the clock is not kept, it is closed anyway. 
>>>
>>> **    without immediate-finish
>>> ** if                      :clock-in t :clock-keep t
>>>     the clock in clocks-in
>>>     BUT the clock is not kept, it is closed anyway. 
>>
>> I can reproduce this problem as well.
>>
>> I don't currently have a use case for :clock-keep so I'm not currently
>> using this feature in my templates.
>
> Ah. This is "bad" from my point of view (but positive on the other
> side). 
> So it seems to me that I am the only one in the list (perhaps with,
> sometimes, Bastien[1]) (1/1100 ?!) willing to use the feature :clock-keep.

I'm not unwilling to use it ... I just haven't found the need to look
for a use-case for it yet. :)

I have a rudimentary capture setup which I'm still in the habit of using
before :clock-keep was invented.  I create a new capture task, fill in
the details (and the clock is now in the capture task) and then file it
with C-c C-c, then the clock resumes on the old task ... then I manually
switch back to the capture task with F9-SPC in my setup which clocks in
the previous task again.

I could change my templates to use :clock-keep in this situation but I'm
not 100% convinced that I always do this.  The F9-SPC is an optional
step to clock in the last task and if I leave the capture task open for
the entire duration of the interruption (such as a phone call) then
stopping the clock when I close the capture task is also correct.

I could probably change my workflow to use :clock-keep instead I just
haven't spent the time on it yet (and obviously the existing problems
with the implementation need to be fixed).

>
> Furthermore it seems to me that the property :clock-keep goes against
> the spirit (and, I think, the implementation) of the capture template:
>
>   "I like this decision [:clock-keep], because of the templates is asked
>    to clock in, it seems natural for me that it will clock out when it is
>    done." 
> -- Carsten, http://article.gmane.org/gmane.emacs.orgmode/38951
>
> So I've a feature request: it may be wise to remove this 
> implementation, to revert commits
>
> b969081ebd0da2711f1006fec39e04fe4a90ef71  : org-capture.el: 
>                            new :no-clock-out template option.
>
> 54c638523d4706d955c9d16cb5f499bcfa92bec9   : org-capture.el: 
>                                   Rename :no-clock-out to :clock-keep.
>

That's a little radical isn't it?  The current problems you've shown are
probably fixable.  Carsten and/or Bastien will need to evaluate what the
best course of action is here.

>
> and .... ;-)
> for my need I've implemented the following hack.
>
> I wrote a function that clocks-in the template 
> *after* I have done with it, and call the function with the 
> org-capture-before-finalize-hook,
> and it does that only for templates with a certain property.
>
>  For I used to have:
>  (add-hook 'org-capture-before-finalize-hook 'org-clock-in)  
>  but it clocked in every capture-template, and I have only *a* template 
>  where I want the clock going on.
>
> Here's the hack:
>
> (add-hook 'org-capture-before-finalize-hook 'gio:capture-clock-keep)
>
> (defun gio:capture-clock-keep ()
> "The function clocks-in only capture buffer with the string \":Rilevazione\".
> It is used in org-capture-before-finalize-hook."
> (interactive)
> ;; the cursor is at the beginning of the capture buffer 
> ;; this simplifies our job ;->
> (when (re-search-forward ":Rilevazione" nil t)
> (org-clock-in))
> )
>
> It is a ugly hack since it keeps the CLOCK lines with 0:00, but 
> I wasn't able to play with the capture buffer anymore...
> (e.g. insert something) and it works for me.

Interesting.  I think finding a proper fix for the current :clock-keep
implementation would make this setup a lot cleaner for you and anyone
else that wants to use it in the future.

>
> cheers,
>
> Giovanni
>
> [1] 'I assume you mean "when :immediate-finish is non-nil in a capture
> template", right?
> Yes, this bugged me as well.'
>
> http://thread.gmane.org/gmane.emacs.orgmode/38485
>
>>> P.S.
>>> While testing I found an unexpected behaviour with :clock-resume
>>>
>>> ** if :immediate-finish t :clock-in t :clock-resume t
>>> *** and If there is no clock to be resumed the clock-in does not
>>>     clock-in in the capture buffer.
>>> Is this  a bug?
>>> Shall be thrown a message: "No clock to be resumed"?
>>
>> I think this is intended behaviour.  If a clock is not already running
>> before you start the capture then there is no task to resume the clock
>> on.  In this case the clock stops after the capture is finalized.
>>
>> Is throwing an error message for this really useful?
> Perhaps not. Just asking. 
> Let's keep things simple.
>
> :-)

:-)

Regards,
Bernt