* Re: Bug: :clock-keep...not kept [7.5 commit-078c01bf3b1742b1015fac9f5bab3a429505f3c6]
@ 2011-04-07 11:31 Giovanni Ridolfi
2011-04-08 2:09 ` Bernt Hansen
0 siblings, 1 reply; 9+ messages in thread
From: Giovanni Ridolfi @ 2011-04-07 11:31 UTC (permalink / raw)
To: Org Mode; +Cc: Bernt Hansen, Carsten Dominik
Hello everyone,
I think I found a bug with the option ":clock-keep"
:clock-keep'
Keep the clock running when filing the captured entry.
Emacs : GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO
Package: Org-mode version 7.5 commit-4168fccdc7eab648d9c4517afe56765aaa1e9664
The option was introduced on 2011-03-07, by Bastien,
in commit:
b969081ebd0da2711f1006fec39e04fe4a90ef71 : org-capture.el:
new :no-clock-out template option.
and, after Carsten chimed in, message:
http://article.gmane.org/gmane.emacs.orgmode/38951
Bastien:
> See my previous message -- I used :no-clock-out to stick to the default
> behavior and avoid users to have to change their config. Let me know if
> this is okay for you!
I like this decision, because of the templates is asked to clock
in, it seems natural for me that it will clock out when it is done.
This only suggestion I would have is it maybe call the property
:clock-keep-running. No sure though.
--------------------------------------------------
in commit
54c638523d4706d955c9d16cb5f499bcfa92bec9 : org-capture.el:
Rename :no-clock-out to :clock-keep.
The thread with the complete discussion is here:
http://thread.gmane.org/gmane.emacs.orgmode/38485
I tried to look at the code to understand it, but it is beyond my skills.
On the other hand I did some tests:
** set up - beware I'm under Windows.
(for Bernt's set up (linuxish) please refer to message
http://thread.gmane.org/gmane.emacs.orgmode/38485 )
My minimal.emacs
--8<---------------cut here---------------start------------->8--
(add-to-list 'load-path (expand-file-name "c:/Documents and Settings/my-path/org/lisp"))
(add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" . org-mode))
(require 'org-install)
(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-ca" 'org-agenda)
(global-set-key "\C-cb" 'org-iswitchb)
(global-set-key "\C-cc" 'org-capture)
(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))))
--8<---------------cut here---------------end--------------->8---
I run emacs with:
c:\path\> emacs -q -l ~/minimal.emacs
C-c c t to call the template.
Fill it in and
C-c C-c to close.
I have modified the properties in the last row:
** if :immediate-finish nil :clock-in t :clock-keep t
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.
cheers,
Giovanni
P.S. Side effect (very emacsish).
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"?
*** If there is clock to be resumed
the clock is resumed. It works.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bug: :clock-keep...not kept [7.5 commit-078c01bf3b1742b1015fac9f5bab3a429505f3c6]
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
0 siblings, 1 reply; 9+ messages in thread
From: Bernt Hansen @ 2011-04-08 2:09 UTC (permalink / raw)
To: Giovanni Ridolfi; +Cc: Org Mode, Carsten Dominik
Hi Giovanni,
Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> writes:
> I think I found a bug with the option ":clock-keep"
>
> :clock-keep'
> Keep the clock running when filing the captured entry.
>
> Emacs : GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on 3249CTO
> Package: Org-mode version 7.5 commit-4168fccdc7eab648d9c4517afe56765aaa1e9664
>
<snip>
> I tried to look at the code to understand it, but it is beyond my skills.
>
> On the other hand I did some tests:
> ** set up - beware I'm under Windows.
> (for Bernt's set up (linuxish) please refer to message
> http://thread.gmane.org/gmane.emacs.orgmode/38485 )
>
> My minimal.emacs
> (add-to-list 'load-path (expand-file-name "c:/Documents and Settings/my-path/org/lisp"))
> (add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" . org-mode))
> (require 'org-install)
>
> (global-set-key "\C-cl" 'org-store-link)
> (global-set-key "\C-ca" 'org-agenda)
> (global-set-key "\C-cb" 'org-iswitchb)
>
> (global-set-key "\C-cc" 'org-capture)
>
> (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 run emacs with:
>
> c:\path\> emacs -q -l ~/minimal.emacs
>
> C-c c t to call the template.
> Fill it in and
> C-c C-c to close.
>
> I have modified the properties in the last row:
>
> ** if :immediate-finish nil :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.
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.
>
> ** 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.
I agree the clock should probably be started and kept in the new capture
task.
>
> cheers,
> Giovanni
>
> P.S. Side effect (very emacsish).
>
> 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"?
>
> *** If there is clock to be resumed
> the clock is resumed. It works.
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?
GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11
on raven, modified by Debian
Regards,
Bernt
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]
2011-04-08 2:09 ` Bernt Hansen
@ 2011-04-08 11:30 ` Giovanni Ridolfi
2011-04-08 12:21 ` Bernt Hansen
0 siblings, 1 reply; 9+ messages in thread
From: Giovanni Ridolfi @ 2011-04-08 11:30 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Bastien, Org Mode, Carsten Dominik
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.
:-)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]
2011-04-08 11:30 ` SOLVED Bug: :clock-keep...not kept [7.5__078c01] Giovanni Ridolfi
@ 2011-04-08 12:21 ` Bernt Hansen
2011-04-08 14:54 ` Giovanni Ridolfi
2011-04-08 16:07 ` Bastien
0 siblings, 2 replies; 9+ messages in thread
From: Bernt Hansen @ 2011-04-08 12:21 UTC (permalink / raw)
To: Giovanni Ridolfi; +Cc: Bastien, Org Mode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]
2011-04-08 12:21 ` Bernt Hansen
@ 2011-04-08 14:54 ` Giovanni Ridolfi
2011-04-08 16:10 ` Bastien
2011-04-08 16:07 ` Bastien
1 sibling, 1 reply; 9+ messages in thread
From: Giovanni Ridolfi @ 2011-04-08 14:54 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Bastien, Org Mode, Carsten Dominik
Bernt Hansen <bernt@norang.ca> writes:
Hi, Bernt,
> Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> writes:
>
>> Bernt Hansen <bernt@norang.ca> writes:
>>
<snip>
>
> 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).
Perhaps you will use it in your todo and/or journal templates (2 out of
6 templates you have, 33% not extensively used.).
>>
>> 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?
Yes it is.
> The current problems you've shown are probably fixable.
_Probably_ fixable; yes, but at what cost?
From what I've understood of the code I think that the idea of closing
anyway the clock, after the capture process is done, is *inside*
the spirit and the design of the capture implementation.
Let's analyse the genesis of capture.
In the good ol'days ;-) of 'remember', we did have the
variable org-remember-clock-out-on-exit.
(ah, the good ol'days) :-D
Why Carsten did not implement such design in capture ?
Answer: "[if] the templates is asked to clock in, it seems natural
for me that it will clock out when it is done."
-- Carsten
So Carsten implemented capture clock to be cloked out on exit. Period.
Then I asked to introduce a varaible clock-out-on-exit, but my request
went unanswered[1].
[1] http://lists.gnu.org/archive/html/emacs-orgmode/2010-07/msg00099.html
> Carsten and/or Bastien will need to evaluate what the
> best course of action is here.
Of course, they have the last word, I'm not a developer.
However let me underline that Bastien tried to introduced
:clock-keep and it does not work. :-(
So I'm conviced that the proper interaction of the :clock-keep
property with the rest of org-capture-finalize
variables it is not a 5' task.
The evaluation of the properties before closing
the template is really nested, not all the case are considered,
only the ones that follow the idea that
the clock shall be closed, if opened in the capture
process.
I think a developer should rewrite /almost enterley/ the function
org-capture-finalize especially the lines from 506 to 522.
So, IMNSHO ;-) *the squeeze does not worth the juice*.
Why spend time only for 2+1? people: me, Bastien and, possibly, you?
Let's be realistic and remember the history:
except you, nobody answered to my mails or jumped in
in such threads. It's clearly a corner case.
Furthermore there's already a solution for the 34%
of people who needs :clock-in, i.e. me: my hack. ;-)
It has the advantage that the user can
set a keyword and decides on the basis of
such kewyword if the clock have to be kept
or not.
You can already exclude your "phone-call template"
from re-clocking, searching the string "* PHONE",
with my hack ;-)
If the hack's ugly I hope Bastien or Carsten will help me in
rewriting it better e.g. removing the 0:00 line without
removing the opened clock, that the org-clock-out-remove-zero-time-clocks
removes :-(. If the do not have time, no problem: it already works
for me.
<snip>
> Interesting. I think finding a proper fix for the current :clock-keep
> implementation would make this setup a lot cleaner for you
Yes the :clock-keep would make the hack unnecessary.
> and anyone
> else that wants to use it in the future.
I doubt. In one year only we 3 have felt the need of such property.
As I said:
>> Let's keep things simple.
if Carsten and Bastien can spend some time hacking org
I'd prefer they merge Jambunathan's org->odt exporter,
than working on a corner case -already solved-
like this one.
cheers, and thank you for having read my messages.
Giovanni
"When it goes and 's good enough,
do not touch or away 'll blast" :-)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]
2011-04-08 12:21 ` Bernt Hansen
2011-04-08 14:54 ` Giovanni Ridolfi
@ 2011-04-08 16:07 ` Bastien
2011-04-11 13:41 ` [PATCH] " Giovanni Ridolfi
1 sibling, 1 reply; 9+ messages in thread
From: Bastien @ 2011-04-08 16:07 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Org Mode, Carsten Dominik
Bernt Hansen <bernt@norang.ca> writes:
> That's a little radical isn't it? The current problems you've shown are
> probably fixable.
It is indeed fixed in the latest git version.
Thanks to both for looking into this.
Best,
--
Bastien
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]
2011-04-08 14:54 ` Giovanni Ridolfi
@ 2011-04-08 16:10 ` Bastien
0 siblings, 0 replies; 9+ messages in thread
From: Bastien @ 2011-04-08 16:10 UTC (permalink / raw)
To: Giovanni Ridolfi; +Cc: Bernt Hansen, Org Mode, Carsten Dominik
Hi Giovanni,
Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> writes:
> However let me underline that Bastien tried to introduced
> :clock-keep and it does not work. :-(
Yes, my bad.
> So I'm conviced that the proper interaction of the :clock-keep
> property with the rest of org-capture-finalize
> variables it is not a 5' task.
It was about a 15 minutes task...
I have been kept away by personal problems but they are now over and I
am back*. So please keep up with reporting problems, whatever they are.
No need to spend too much time on trying to figure out how much time it
costs to solve a problem :)
Best,
* I know, this is kind of a motto now, but this time is for good.
--
Bastien
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] Re: Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]
2011-04-08 16:07 ` Bastien
@ 2011-04-11 13:41 ` Giovanni Ridolfi
2011-05-13 12:50 ` Carsten Dominik
0 siblings, 1 reply; 9+ messages in thread
From: Giovanni Ridolfi @ 2011-04-11 13:41 UTC (permalink / raw)
To: Bastien; +Cc: Org Mode
Bastien <bzg@altern.org> writes:
> It is indeed fixed in the latest git version.
Bastien,
The :clock-keep option now works, thanks.
There's a little bug in the Customize interface of clock-keep.
The :clock-keep *t* option can't be selected with the Customize
interface 'C-c c C ', since its value is 'nil'.
The following patch fixes it.
cheers,
Giovanni
From: Giovanni Ridolfi <giovanni.ridolfi@yahoo.it>
Subject: [PATCH] Fix bug in customize interface of :clock-keep
Date: Mon, 11 Apr 2011 15:07:11 +0200
* lisp/org-capture.el (org-capture-templates): set the value of :clock-keep to t.
TinyChange
---
--- org-capture.el 2011-04-11 00:29:00.000000000 +0200
+++ org-capture-2.el 2011-04-11 14:41:30.465497600 +0200
@@ -323,5 +323,5 @@
((const :format "%v " :empty-lines) (const 1))
((const :format "%v " :clock-in) (const t))
- ((const :format "%v " :clock-keep) (const nil))
+ ((const :format "%v " :clock-keep) (const t))
((const :format "%v " :clock-resume) (const t))
((const :format "%v " :unnarrowed) (const t))
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Re: Re: SOLVED Bug: :clock-keep...not kept [7.5__078c01]
2011-04-11 13:41 ` [PATCH] " Giovanni Ridolfi
@ 2011-05-13 12:50 ` Carsten Dominik
0 siblings, 0 replies; 9+ messages in thread
From: Carsten Dominik @ 2011-05-13 12:50 UTC (permalink / raw)
To: Giovanni Ridolfi; +Cc: Bastien, Org Mode
Applied, thanks
On Apr 11, 2011, at 3:41 PM, Giovanni Ridolfi wrote:
> Bastien <bzg@altern.org> writes:
>
>> It is indeed fixed in the latest git version.
>
>
> Bastien,
>
> The :clock-keep option now works, thanks.
>
> There's a little bug in the Customize interface of clock-keep.
>
> The :clock-keep *t* option can't be selected with the Customize
> interface 'C-c c C ', since its value is 'nil'.
>
> The following patch fixes it.
>
> cheers,
> Giovanni
>
>
> From: Giovanni Ridolfi <giovanni.ridolfi@yahoo.it>
> Subject: [PATCH] Fix bug in customize interface of :clock-keep
> Date: Mon, 11 Apr 2011 15:07:11 +0200
>
>
> * lisp/org-capture.el (org-capture-templates): set the value of :clock-keep to t.
>
> TinyChange
> ---
> --- org-capture.el 2011-04-11 00:29:00.000000000 +0200
> +++ org-capture-2.el 2011-04-11 14:41:30.465497600 +0200
> @@ -323,5 +323,5 @@
> ((const :format "%v " :empty-lines) (const 1))
> ((const :format "%v " :clock-in) (const t))
> - ((const :format "%v " :clock-keep) (const nil))
> + ((const :format "%v " :clock-keep) (const t))
> ((const :format "%v " :clock-resume) (const t))
> ((const :format "%v " :unnarrowed) (const t))
>
- Carsten
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-05-13 12:50 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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).