From: Bernt Hansen <bernt@norang.ca>
To: Giovanni Ridolfi <giovanni.ridolfi@yahoo.it>
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 08:21:49 -0400 [thread overview]
Message-ID: <871v1d2asi.fsf@norang.ca> (raw)
In-Reply-To: <83ipup6kvz.fsf_-_@yahoo.it> (Giovanni Ridolfi's message of "Fri, 08 Apr 2011 13:30:08 +0200")
Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> writes:
> 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.
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
next prev parent reply other threads:[~2011-04-08 12:22 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 ` SOLVED Bug: :clock-keep...not kept [7.5__078c01] Giovanni Ridolfi
2011-04-08 12:21 ` Bernt Hansen [this message]
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=871v1d2asi.fsf@norang.ca \
--to=bernt@norang.ca \
--cc=bastien.guerry@wikimedia.fr \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=giovanni.ridolfi@yahoo.it \
/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).