Giovanni Ridolfi <giovanni.rido...@yahoo.it> writes: > Bernt Hansen <be...@norang.ca> writes: > > Hi Bernt, >> Giovanni Ridolfi <giovanni.rido...@yahoo.it> 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