emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Giovanni Ridolfi <giovanni.ridolfi@yahoo.it>
To: Bernt Hansen <bernt@norang.ca>
Cc: Bastien <bastien.guerry@wikimedia.fr>,
	Org Mode <emacs-orgmode@gnu.org>,
	Carsten Dominik <carsten.dominik@gmail.com>
Subject: Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]
Date: Fri, 08 Apr 2011 13:30:08 +0200	[thread overview]
Message-ID: <83ipup6kvz.fsf_-_@yahoo.it> (raw)
In-Reply-To: <87wrj5335f.fsf@norang.ca> (Bernt Hansen's message of "Thu, 07 Apr 2011 22:09:16 -0400")

Bernt Hansen <bernt@norang.ca> writes:

Hi Bernt,
> Giovanni Ridolfi <giovanni.ridolfi@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.
>>    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.

:-)

  reply	other threads:[~2011-04-08 11:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-07 11:31 Bug: :clock-keep...not kept [7.5 commit-078c01bf3b1742b1015fac9f5bab3a429505f3c6] Giovanni Ridolfi
2011-04-08  2:09 ` Bernt Hansen
2011-04-08 11:30   ` Giovanni Ridolfi [this message]
2011-04-08 12:21     ` SOLVED Bug: :clock-keep...not kept [7.5__078c01] Bernt Hansen
2011-04-08 14:54       ` Giovanni Ridolfi
2011-04-08 16:10         ` Bastien
2011-04-08 16:07       ` Bastien
2011-04-11 13:41         ` [PATCH] " Giovanni Ridolfi
2011-05-13 12:50           ` Carsten Dominik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83ipup6kvz.fsf_-_@yahoo.it \
    --to=giovanni.ridolfi@yahoo.it \
    --cc=bastien.guerry@wikimedia.fr \
    --cc=bernt@norang.ca \
    --cc=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).