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 13:30:08 +0200 Message-ID: <83ipup6kvz.fsf_-_@yahoo.it> References: <83pqoyfgbh.fsf@yahoo.it> <87wrj5335f.fsf@norang.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=53292 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q89s6-00053C-CT for emacs-orgmode@gnu.org; Fri, 08 Apr 2011 07:29:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q89s4-0008Rj-Oa for emacs-orgmode@gnu.org; Fri, 08 Apr 2011 07:29:02 -0400 Received: from nm1.bullet.mail.ukl.yahoo.com ([217.146.183.218]:29871) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Q89s4-0008Qu-AR for emacs-orgmode@gnu.org; Fri, 08 Apr 2011 07:29:00 -0400 In-Reply-To: <87wrj5335f.fsf@norang.ca> (Bernt Hansen's message of "Thu, 07 Apr 2011 22:09:16 -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: > >> I think I found a bug with the option ":clock-keep" >> >> (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)))) >> >> 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. >> 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. 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. >> ** 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. 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. 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. 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. :-)