From mboxrd@z Thu Jan 1 00:00:00 1970 From: Giovanni Ridolfi Subject: Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01] Date: Fri, 08 Apr 2011 16:54:06 +0200 Message-ID: <83y63k6bg1.fsf@yahoo.it> References: <83pqoyfgbh.fsf@yahoo.it> <87wrj5335f.fsf@norang.ca> <83ipup6kvz.fsf_-_@yahoo.it> <871v1d2asi.fsf@norang.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=42327 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8D3W-00082I-Dl for emacs-orgmode@gnu.org; Fri, 08 Apr 2011 10:53:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q8D3R-0005XK-SO for emacs-orgmode@gnu.org; Fri, 08 Apr 2011 10:53:02 -0400 Received: from nm7.bullet.mail.ukl.yahoo.com ([217.146.182.248]:37258) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Q8D3R-0005VW-H1 for emacs-orgmode@gnu.org; Fri, 08 Apr 2011 10:52:57 -0400 In-Reply-To: <871v1d2asi.fsf@norang.ca> (Bernt Hansen's message of "Fri, 08 Apr 2011 08:21:49 -0400") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bernt Hansen Cc: Bastien , Org Mode , Carsten Dominik Bernt Hansen writes: Hi, Bernt, > Giovanni Ridolfi writes: > >> Bernt Hansen writes: >> > > 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. > 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" :-)