[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Giovanni Ridolfi
Subject: [O] Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]
Date: Fri, 08 Apr 2011 13:30:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (windows-nt)

Bernt Hansen <address@hidden> writes:

Hi Bernt,
> Giovanni Ridolfi <address@hidden> 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
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
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
-- 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 
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."
;; the cursor is at the beginning of the capture buffer 
;; this simplifies our job ;->
(when (re-search-forward ":Rilevazione" nil t)

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.



[1] 'I assume you mean "when :immediate-finish is non-nil in a capture
template", right?
Yes, this bugged me as well.'


>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]