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

[Giovanni Ridolfi]

Bernt Hansen <address@hidden> writes:

Hi, Bernt,
> Giovanni Ridolfi <address@hidden> writes:
>
>> Bernt Hansen <address@hidden> writes:
>>
<snip>
>
> 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).

Perhaps you will use it in your todo and/or journal templates (2 out of
6 templates you have, 33% not extensively used.).

>>
>> 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?  
Yes it is.
> The current problems you've shown are probably fixable.  

_Probably_ fixable; yes, but at what cost? 

>From what I've understood of the code I think that the idea of closing 
anyway the clock, after the capture process is done, is *inside* 
the spirit and the design of the capture implementation.

Let's analyse the genesis of capture.
 In the good ol'days ;-) of 'remember', we did have the
 variable org-remember-clock-out-on-exit.
 (ah, the good ol'days) :-D

Why Carsten did not implement such design in capture ?
Answer:  "[if] the templates is asked to clock in, it seems natural 
  for me that it will clock out when it is done." 
   -- Carsten

So Carsten implemented capture clock to be cloked out on exit. Period.

Then I asked to introduce a varaible clock-out-on-exit, but my request
went unanswered[1].

[1] http://lists.gnu.org/archive/html/emacs-orgmode/2010-07/msg00099.html

> Carsten and/or Bastien will need to evaluate what the
> best course of action is here.

Of course, they have the last word, I'm not a developer. 

However let me underline that Bastien tried to introduced
:clock-keep and it does not work. :-(

So I'm conviced that the proper interaction of the :clock-keep 
property with the rest of org-capture-finalize 
variables it is not a 5' task.

The evaluation of the properties before closing 
the template is really nested, not all the case are considered,
only the ones that follow the idea that
the clock shall be closed, if opened in the capture
process.
I think a developer should rewrite /almost enterley/ the function 
org-capture-finalize especially the lines from 506 to 522.

So, IMNSHO ;-) *the squeeze does not worth the juice*.

Why spend time only for 2+1? people: me, Bastien and, possibly, you?

Let's be realistic and remember the history:
except you, nobody answered to my mails or jumped in 
in such threads. It's clearly a corner case.

Furthermore there's already a solution for the 34%
of people who needs :clock-in, i.e. me: my hack. ;-)

It has the advantage that the user can 
set a keyword and decides on the basis of
such kewyword if the clock have to be kept
or not. 
You can already exclude your "phone-call template" 
from re-clocking, searching the string "* PHONE",
with my hack ;-)

If the hack's ugly I hope Bastien or Carsten will help me in 
rewriting it better e.g. removing the 0:00 line without
removing the opened clock, that the org-clock-out-remove-zero-time-clocks
removes :-(. If the do not have time, no problem: it already works
for me.

<snip>

> Interesting.  I think finding a proper fix for the current :clock-keep
> implementation would make this setup a lot cleaner for you 
Yes the :clock-keep would make the hack unnecessary.

> and anyone
> else that wants to use it in the future.

I doubt. In one year only we 3 have felt the need of such property.

As I said:
>> Let's keep things simple.

if Carsten and Bastien can spend some time hacking org
I'd prefer they merge Jambunathan's org->odt exporter,
than working on a corner case -already solved- 
like this one.

cheers, and thank you for having read my messages.

Giovanni

"When it goes and 's good enough,
 do not touch or away 'll blast"  :-)