emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* done-ing a repeating scheduled task now inserts closed timestamp?
@ 2009-03-03  1:29 Samuel Wales
  2009-03-03  8:56 ` Manuel Hermenegildo
  2009-03-04  6:17 ` Carsten Dominik
  0 siblings, 2 replies; 12+ messages in thread
From: Samuel Wales @ 2009-03-03  1:29 UTC (permalink / raw)
  To: emacs-orgmode

Nobody else has commented on this, so perhaps I am doing something wrong.

My recollection is that [setting the todo state of a task with a
repeating scheduled task to done] did not used to insert a closed
timestamp, but now it seems to -- or at least it fails to remove the
timestamp.  Is this intentional?

I use the closed timestamp to indicate that a task can be archived,
but perhaps I should not rely on that?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-03  1:29 done-ing a repeating scheduled task now inserts closed timestamp? Samuel Wales
@ 2009-03-03  8:56 ` Manuel Hermenegildo
  2009-03-04 13:03   ` Carsten Dominik
                     ` (2 more replies)
  2009-03-04  6:17 ` Carsten Dominik
  1 sibling, 3 replies; 12+ messages in thread
From: Manuel Hermenegildo @ 2009-03-03  8:56 UTC (permalink / raw)
  To: Samuel Wales; +Cc: emacs-orgmode


 > Nobody else has commented on this, so perhaps I am doing something wrong.
 > 
 > My recollection is that [setting the todo state of a task with a
 > repeating scheduled task to done] did not used to insert a closed
 > timestamp, but now it seems to -- or at least it fails to remove the
 > timestamp.  Is this intentional?
 > 
 > I use the closed timestamp to indicate that a task can be archived,
 > but perhaps I should not rely on that?

I find that most things in org behave in a way that works for me right
away, which shows how much thinking goes into its design.  However
repeated tasks is one thing that has not quite worked for me
yet. Repeating items and cyclic diary entries provide part of the
functionality I need, but not quite.

Basically, I would like repeated tasks and cyclic appointments to
disappear from the past when they are done (so that they do not
clutter the agenda) but to appear in the future (so that I can, e.g.,
schedule other appointments around them in the days they occur).

Repeating tasks do not appear in the future or the past. Cyclic
appointments are close. If I have:

** TODO Check backups     <2009-03-05 Thu 11:00 +2d>

And pass from TODO to DONE this happens:

** TODO Check backups     <2009-03-07 Sat 11:00 +2d>
   CLOSED: [2009-03-05 Tue 07:57]
   - State "DONE"       from "TODO"       [2009-03-03 Tue 07:57]

An then, with "l" this entry will appear in the agenda, but:

- It appears as TODO (rather than DONE) and with the current date,
  (even though it also does say "Closed:") all of which can be
  confusing.

- Non-repeating tasks with a timestamp behave differently: if such a
  task is marked as done a CLOSED line is also generated (provided the
  right flags are on) but it does not actually disappear from the
  agenda (at least for me, even if the manual seems to imply
  otherwise), independently of the logging ("l") state.

I think a perhaps better behavior could be that the same line:

** TODO Check backups     <2009-03-05 Thu 11:00 +2d>

is marked as done, then a) a *copy* is made of the TODO item, and that
copy is the one that goes to DONE and gets the CLOSED (i.e., a
"normal" task is generated and updated) and b) the repeating task is
shifted (without attaching anything to it, since it is a "fresh"
task):

** DONE Check backups     <2009-03-05 Sat 11:00>
   CLOSED: [2009-03-05 Tue 07:57]
   - State "DONE"       from "TODO"       [2009-03-03 Tue 07:57]
** TODO Check backups     <2009-03-07 Sat 11:00 +2d>

Apart from behaving more like a normal task this would have in my mind
some additional advantages: I like DONE tasks to eventually disappear
from my agenda. I do this by archiving them (to sibling). This allows
me to easily see that I have not left anything behind in past days. I
could now do this with the copied task, independently of the updated
repeater. When I want to look at what I did on a certain day I hit the
handy "v" key and the archived, done tasks appear again, including
those that originated from the repeater --great!  I.e., the
repeater leaves behind a trail of normal tasks.

Thoughts?

Manuel

-- 
-------------------------------------------------------------------------------
 Manuel Hermenegildo                     | Prof., C.S.Dept., T.U. Madrid (UPM)
 Director, IMDEA-Software and CLIP Group | +34-91-336-7435 (W) -352-4819 (Fax)
-------------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-03  1:29 done-ing a repeating scheduled task now inserts closed timestamp? Samuel Wales
  2009-03-03  8:56 ` Manuel Hermenegildo
@ 2009-03-04  6:17 ` Carsten Dominik
  1 sibling, 0 replies; 12+ messages in thread
From: Carsten Dominik @ 2009-03-04  6:17 UTC (permalink / raw)
  To: Samuel Wales; +Cc: emacs-orgmode


On Mar 3, 2009, at 2:29 AM, Samuel Wales wrote:

> Nobody else has commented on this, so perhaps I am doing something  
> wrong.
>
> My recollection is that [setting the todo state of a task with a
> repeating scheduled task to done] did not used to insert a closed
> timestamp, but now it seems to -- or at least it fails to remove the
> timestamp.  Is this intentional?


No, this is a bug, introduced when I tried fixing the empty line
problem you reported.

Fixed now, I hope.

- Carsten

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-03  8:56 ` Manuel Hermenegildo
@ 2009-03-04 13:03   ` Carsten Dominik
  2009-03-04 14:26     ` Bernt Hansen
  2009-03-04 13:15   ` Bernt Hansen
  2009-03-04 13:30   ` Carsten Dominik
  2 siblings, 1 reply; 12+ messages in thread
From: Carsten Dominik @ 2009-03-04 13:03 UTC (permalink / raw)
  To: Manuel Hermenegildo; +Cc: emacs-orgmode


On Mar 3, 2009, at 9:56 AM, Manuel Hermenegildo wrote:

>
>> Nobody else has commented on this, so perhaps I am doing something  
>> wrong.
>>
>> My recollection is that [setting the todo state of a task with a
>> repeating scheduled task to done] did not used to insert a closed
>> timestamp, but now it seems to -- or at least it fails to remove the
>> timestamp.  Is this intentional?
>>
>> I use the closed timestamp to indicate that a task can be archived,
>> but perhaps I should not rely on that?
>
> I find that most things in org behave in a way that works for me right
> away, which shows how much thinking goes into its design.  However
> repeated tasks is one thing that has not quite worked for me
> yet. Repeating items and cyclic diary entries provide part of the
> functionality I need, but not quite.
>
> Basically, I would like repeated tasks and cyclic appointments to
> disappear from the past when they are done (so that they do not
> clutter the agenda) but to appear in the future (so that I can, e.g.,
> schedule other appointments around them in the days they occur).
>
> Repeating tasks do not appear in the future or the past. Cyclic
> appointments are close. If I have:

They do appear in the future if you have
org-agenda-repeating-timestamp-show-all
set to t (which is also the default)

> ** TODO Check backups     <2009-03-05 Thu 11:00 +2d>
>
> And pass from TODO to DONE this happens:
>
> ** TODO Check backups     <2009-03-07 Sat 11:00 +2d>
>  CLOSED: [2009-03-05 Tue 07:57]

That CLOSED show up here is a bug, reported by Samuel Wales,
fixed by now.

>
>  - State "DONE"       from "TODO"       [2009-03-03 Tue 07:57]
>
> An then, with "l" this entry will appear in the agenda, but:

Part of the bug that it shows up with "l", it should not.
No longer does, I think.

>
>
> - It appears as TODO (rather than DONE) and with the current date,
> (even though it also does say "Closed:") all of which can be
> confusing.
>
> - Non-repeating tasks with a timestamp behave differently: if such a
> task is marked as done a CLOSED line is also generated (provided the
> right flags are on) but it does not actually disappear from the
> agenda (at least for me, even if the manual seems to imply
> otherwise), independently of the logging ("l") state.

You can make DONE scheduled tasks disappear by setting
org-agenda-skip-scheduled-if-done

Where does the manual state otherwise?

>
>
> I think a perhaps better behavior could be that the same line:
>
> ** TODO Check backups     <2009-03-05 Thu 11:00 +2d>
>
> is marked as done, then a) a *copy* is made of the TODO item, and that
> copy is the one that goes to DONE and gets the CLOSED (i.e., a
> "normal" task is generated and updated) and b) the repeating task is
> shifted (without attaching anything to it, since it is a "fresh"
> task):
>
> ** DONE Check backups     <2009-03-05 Sat 11:00>
>  CLOSED: [2009-03-05 Tue 07:57]
>  - State "DONE"       from "TODO"       [2009-03-03 Tue 07:57]
> ** TODO Check backups     <2009-03-07 Sat 11:00 +2d>
>
> Apart from behaving more like a normal task this would have in my mind
> some additional advantages: I like DONE tasks to eventually disappear
> from my agenda. I do this by archiving them (to sibling). This allows
> me to easily see that I have not left anything behind in past days. I
> could now do this with the copied task, independently of the updated
> repeater. When I want to look at what I did on a certain day I hit the
> handy "v" key and the archived, done tasks appear again, including
> those that originated from the repeater --great!  I.e., the
> repeater leaves behind a trail of normal tasks.

This is an interesting, alternative proposal for repeating tasks.

Anyone else would like to comment on this?

- Carsten

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-03  8:56 ` Manuel Hermenegildo
  2009-03-04 13:03   ` Carsten Dominik
@ 2009-03-04 13:15   ` Bernt Hansen
  2009-03-04 13:30   ` Carsten Dominik
  2 siblings, 0 replies; 12+ messages in thread
From: Bernt Hansen @ 2009-03-04 13:15 UTC (permalink / raw)
  To: Manuel Hermenegildo; +Cc: emacs-orgmode

Manuel Hermenegildo <herme@fi.upm.es> writes:

> Repeating tasks do not appear in the future or the past. Cyclic
> appointments are close. If I have:
>
> ** TODO Check backups     <2009-03-05 Thu 11:00 +2d>
>
> And pass from TODO to DONE this happens:
>
> ** TODO Check backups     <2009-03-07 Sat 11:00 +2d>
>    CLOSED: [2009-03-05 Tue 07:57]
>    - State "DONE"       from "TODO"       [2009-03-03 Tue 07:57]
>
> An then, with "l" this entry will appear in the agenda, but:
>
> - It appears as TODO (rather than DONE) and with the current date,
>   (even though it also does say "Closed:") all of which can be
>   confusing.
>
> - Non-repeating tasks with a timestamp behave differently: if such a
>   task is marked as done a CLOSED line is also generated (provided the
>   right flags are on) but it does not actually disappear from the
>   agenda (at least for me, even if the manual seems to imply
>   otherwise), independently of the logging ("l") state.
>

<snip>

>
> Thoughts?

I think it will work better if you use SCHEDULED: dates like this:

** TODO Check backups
   SCHEDULED: <2009-03-05 Thu 11:00 +2d>

-Bernt

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-03  8:56 ` Manuel Hermenegildo
  2009-03-04 13:03   ` Carsten Dominik
  2009-03-04 13:15   ` Bernt Hansen
@ 2009-03-04 13:30   ` Carsten Dominik
  2 siblings, 0 replies; 12+ messages in thread
From: Carsten Dominik @ 2009-03-04 13:30 UTC (permalink / raw)
  To: Manuel Hermenegildo; +Cc: emacs-orgmode


On Mar 3, 2009, at 9:56 AM, Manuel Hermenegildo wrote:

>
>> Nobody else has commented on this, so perhaps I am doing something  
>> wrong.
>>
>> My recollection is that [setting the todo state of a task with a
>> repeating scheduled task to done] did not used to insert a closed
>> timestamp, but now it seems to -- or at least it fails to remove the
>> timestamp.  Is this intentional?
>>
>> I use the closed timestamp to indicate that a task can be archived,
>> but perhaps I should not rely on that?
>
> I find that most things in org behave in a way that works for me right
> away, which shows how much thinking goes into its design.  However
> repeated tasks is one thing that has not quite worked for me
> yet. Repeating items and cyclic diary entries provide part of the
> functionality I need, but not quite.
>
> Basically, I would like repeated tasks and cyclic appointments to
> disappear from the past when they are done (so that they do not
> clutter the agenda) but to appear in the future (so that I can, e.g.,
> schedule other appointments around them in the days they occur).
>
> Repeating tasks do not appear in the future or the past. Cyclic
> appointments are close. If I have:
>
> ** TODO Check backups     <2009-03-05 Thu 11:00 +2d>
>
> And pass from TODO to DONE this happens:
>
> ** TODO Check backups     <2009-03-07 Sat 11:00 +2d>
>   CLOSED: [2009-03-05 Tue 07:57]
>   - State "DONE"       from "TODO"       [2009-03-03 Tue 07:57]
>
> An then, with "l" this entry will appear in the agenda, but:
>
> - It appears as TODO (rather than DONE) and with the current date,
>  (even though it also does say "Closed:") all of which can be
>  confusing.
>
> - Non-repeating tasks with a timestamp behave differently: if such a
>  task is marked as done a CLOSED line is also generated (provided the
>  right flags are on) but it does not actually disappear from the
>  agenda (at least for me, even if the manual seems to imply
>  otherwise), independently of the logging ("l") state.
>
> I think a perhaps better behavior could be that the same line:
>
> ** TODO Check backups     <2009-03-05 Thu 11:00 +2d>
>
> is marked as done, then a) a *copy* is made of the TODO item, and that
> copy is the one that goes to DONE and gets the CLOSED (i.e., a
> "normal" task is generated and updated) and b) the repeating task is
> shifted (without attaching anything to it, since it is a "fresh"
> task):
>
> ** DONE Check backups     <2009-03-05 Sat 11:00>
>   CLOSED: [2009-03-05 Tue 07:57]
>   - State "DONE"       from "TODO"       [2009-03-03 Tue 07:57]
> ** TODO Check backups     <2009-03-07 Sat 11:00 +2d>
>
> Apart from behaving more like a normal task this would have in my mind
> some additional advantages: I like DONE tasks to eventually disappear
> from my agenda. I do this by archiving them (to sibling). This allows
> me to easily see that I have not left anything behind in past days. I
> could now do this with the copied task, independently of the updated
> repeater. When I want to look at what I did on a certain day I hit the
> handy "v" key and the archived, done tasks appear again, including
> those that originated from the repeater --great!  I.e., the
> repeater leaves behind a trail of normal tasks.

Another idea to get this:

Turn on state change notes or at least time stamps.  Either globally,
or locally for this entry with a LOGGING property:

** TODO Check backups
     SCHEDULED: <2009-03-05 Thu 11:00 +2d>
    :PROPERTIES:
    :LOGGING: DONE(!)
    :END:

(yes, scheduled, thanks Bernt...)
Then each time you go through the DONE state, a time stamp
will be recorded like this (I am assuming that you have
org-log-into-drawer set...)

** TODO Check backups
    SCHEDULED: <2009-04-28 Tue 11:00 +2d>
    :LOGBOOK:
    - State "DONE"       from "TODO"       [2009-03-04 Wed 14:25]
    - State "DONE"       from "TODO"       [2009-03-02 Mon 14:25]
    - State "DONE"       from "TODO"       [2009-02-28 Sat 14:25]
    - State "DONE"       from "TODO"       [2009-02-26 Thu 14:25]
    :END:
    :PROPERTIES:
    :LOGGING:  DONE(!)

In the agenda, if you press `C-u l', these state notes
will become visible.

I believe this will take care of it, right??

- Carsten



>
>
> Thoughts?
>
> Manuel
>
> -- 
> -------------------------------------------------------------------------------
> Manuel Hermenegildo                     | Prof., C.S.Dept., T.U.  
> Madrid (UPM)
> Director, IMDEA-Software and CLIP Group | +34-91-336-7435 (W)  
> -352-4819 (Fax)
> -------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-04 13:03   ` Carsten Dominik
@ 2009-03-04 14:26     ` Bernt Hansen
  2009-03-06 16:49       ` Carsten Dominik
  0 siblings, 1 reply; 12+ messages in thread
From: Bernt Hansen @ 2009-03-04 14:26 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: emacs-orgmode

Carsten Dominik <dominik@science.uva.nl> writes:

> On Mar 3, 2009, at 9:56 AM, Manuel Hermenegildo wrote:
>
>> I think a perhaps better behavior could be that the same line:
>>
>> ** TODO Check backups     <2009-03-05 Thu 11:00 +2d>
>>
>> is marked as done, then a) a *copy* is made of the TODO item, and that
>> copy is the one that goes to DONE and gets the CLOSED (i.e., a
>> "normal" task is generated and updated) and b) the repeating task is
>> shifted (without attaching anything to it, since it is a "fresh"
>> task):
>>
>> ** DONE Check backups     <2009-03-05 Sat 11:00>
>>  CLOSED: [2009-03-05 Tue 07:57]
>>  - State "DONE"       from "TODO"       [2009-03-03 Tue 07:57]
>> ** TODO Check backups     <2009-03-07 Sat 11:00 +2d>
>>
>> Apart from behaving more like a normal task this would have in my mind
>> some additional advantages: I like DONE tasks to eventually disappear
>> from my agenda. I do this by archiving them (to sibling). This allows
>> me to easily see that I have not left anything behind in past days. I
>> could now do this with the copied task, independently of the updated
>> repeater. When I want to look at what I did on a certain day I hit the
>> handy "v" key and the archived, done tasks appear again, including
>> those that originated from the repeater --great!  I.e., the
>> repeater leaves behind a trail of normal tasks.
>
> This is an interesting, alternative proposal for repeating tasks.
>
> Anyone else would like to comment on this?

Here are some comments :)

I've thought that copying the repeated task would be useful as well but
it might not be worth the effort to get it right for the general case.

My concern in copying it is I want most of the content copied too.  I
regularly add check box lists to repeated tasks with a list of things to
do and properties to reset the check boxes.

The new copied task would ideally (for me) keep the :PROPERTIES: drawer
and the content but not the :LOGBOOK: drawer.

Any notes and things would go in the LOGBOOK drawer that shouldn't be
carried forward.

,----[ before copy ]
| ** TODO Weekly Review
|    SCHEDULED: <2009-03-09 Mon ++1w>
|    :LOGBOOK:...
|    :PROPERTIES:
|    :RESET_CHECK_BOXES: t
|    :END:
| 
|    - [ ] Do this
|    - [ ] Do that
|    - [ ] Do another thing
| 
|    Skip these
| 
|    - [ ] Used to be Important task 1
|    - [ ] Used to be Important task 2
| 
| ** Next task
`----

After copying for repeat I'd like the new task to be:

,----[ after copy (new copied task) ]
| ** TODO Weekly Review
|    SCHEDULED: <2009-03-16 Mon ++1w>
|    :PROPERTIES:
|    :RESET_CHECK_BOXES: t
|    :END:
| 
|    - [ ] Do this
|    - [ ] Do that
|    - [ ] Do another thing
| 
|    Skip these
| 
|    - [ ] Used to be Important task 1
|    - [ ] Used to be Important task 2
| 
| ** Next task
`----

The DONE task should probably have the check boxes retained checked, and
the new copy has the checkboxes cleared.  This seems like it could get
overly complicated real fast. :(

I could also see this for more involved tasks where you want to
propagate the subtree too (like my bookkeeping task has lots of steps
which I keep as separate tasks below the repeated tasks).

Copying the level 2 task (Q2 Accounting) would need to copy all of the
subtasks in the tree and strip out the :LOGBOOK: drawers from the copy.


------------------------------------------------------------------------
** TODO Q2 Accounting						       :PROJECT:
   DEADLINE: <2009-04-30 Thu +1y> 
   :PROPERTIES:
   :Effort:   3:00
   :ORDERED: t
   :END:
*** TODO January Accounting [0/17] [0%] 					  :NEXT:
    :LOGBOOK:...
    :PROPERTIES:
    :RESET_CHECK_BOXES: t
    :END:
      - [ ] Enter Personal Expenses
      - [ ] Enter credit card charges
      - [ ] Balance credit card statement
      - [ ] Enter Cheques and payments
      - [ ] Enter Invoices - Receive Payments
      - [ ] Balance Bank accounts
      ...
      - [ ] Get USD value at month end
      - [ ] Foreign Exchange Adjustments
      - [ ] Print Reports
      - [ ] File receipts and reports

*** TODO February Accounting [0/17] [0%]...
*** TODO Mileage Jan - Mar
     :PROPERTIES:...

|   | Date        | Car     |  From |    To | Total | Where      | Why                       |
|---+-------------+---------+-------+-------+-------+------------+---------------------------|
| # |             |         |       |       |       |            |                           |

*** TODO March Accounting [0/17] [0%]...
**** TODO Record personal mileage details...
*** TODO GST [0/3] [0%]
    :LOGBOOK:...
    :PROPERTIES:
    :Effort:   0:10
    :RESET_CHECK_BOXES: t
    :END:

   - [ ] Print GST Reports
   - [ ] File receipts and reports
   - [ ] File GST Tax Return

------------------------------------------------------------------------

After writing all this... it would probably be easier just to extract
out the :LOGBOOK: entries and duplicate the subtree structure for the
completed tasks.  (ie. the copy is the completed task and just
reschedule the existing task into the future like we do now)

It might be nice to have a way to have some subtasks in the tree _not_
be copied.  If you have something to remember for this upcoming repeated
task you create a subtask for that... but you won't need that in the
repeated task.

Regards,
Bernt

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-04 14:26     ` Bernt Hansen
@ 2009-03-06 16:49       ` Carsten Dominik
  2009-03-07 21:26         ` Bernt Hansen
  2009-03-08 18:25         ` Manuel Hermenegildo
  0 siblings, 2 replies; 12+ messages in thread
From: Carsten Dominik @ 2009-03-06 16:49 UTC (permalink / raw)
  To: Bernt Hansen; +Cc: emacs-orgmode

Hi Bernt,

to me this sounds like a pretty convincing argument *not*
to copy entries...

Another problem is that entries can have IDs, and I
would like the ID of such an entry to remain the same,
as a link target.

- Carsten

On Mar 4, 2009, at 3:26 PM, Bernt Hansen wrote:

> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> On Mar 3, 2009, at 9:56 AM, Manuel Hermenegildo wrote:
>>
>>> I think a perhaps better behavior could be that the same line:
>>>
>>> ** TODO Check backups     <2009-03-05 Thu 11:00 +2d>
>>>
>>> is marked as done, then a) a *copy* is made of the TODO item, and  
>>> that
>>> copy is the one that goes to DONE and gets the CLOSED (i.e., a
>>> "normal" task is generated and updated) and b) the repeating task is
>>> shifted (without attaching anything to it, since it is a "fresh"
>>> task):
>>>
>>> ** DONE Check backups     <2009-03-05 Sat 11:00>
>>> CLOSED: [2009-03-05 Tue 07:57]
>>> - State "DONE"       from "TODO"       [2009-03-03 Tue 07:57]
>>> ** TODO Check backups     <2009-03-07 Sat 11:00 +2d>
>>>
>>> Apart from behaving more like a normal task this would have in my  
>>> mind
>>> some additional advantages: I like DONE tasks to eventually  
>>> disappear
>>> from my agenda. I do this by archiving them (to sibling). This  
>>> allows
>>> me to easily see that I have not left anything behind in past  
>>> days. I
>>> could now do this with the copied task, independently of the updated
>>> repeater. When I want to look at what I did on a certain day I hit  
>>> the
>>> handy "v" key and the archived, done tasks appear again, including
>>> those that originated from the repeater --great!  I.e., the
>>> repeater leaves behind a trail of normal tasks.
>>
>> This is an interesting, alternative proposal for repeating tasks.
>>
>> Anyone else would like to comment on this?
>
> Here are some comments :)
>
> I've thought that copying the repeated task would be useful as well  
> but
> it might not be worth the effort to get it right for the general case.
>
> My concern in copying it is I want most of the content copied too.  I
> regularly add check box lists to repeated tasks with a list of  
> things to
> do and properties to reset the check boxes.
>
> The new copied task would ideally (for me) keep the :PROPERTIES:  
> drawer
> and the content but not the :LOGBOOK: drawer.
>
> Any notes and things would go in the LOGBOOK drawer that shouldn't be
> carried forward.
>
> ,----[ before copy ]
> | ** TODO Weekly Review
> |    SCHEDULED: <2009-03-09 Mon ++1w>
> |    :LOGBOOK:...
> |    :PROPERTIES:
> |    :RESET_CHECK_BOXES: t
> |    :END:
> |
> |    - [ ] Do this
> |    - [ ] Do that
> |    - [ ] Do another thing
> |
> |    Skip these
> |
> |    - [ ] Used to be Important task 1
> |    - [ ] Used to be Important task 2
> |
> | ** Next task
> `----
>
> After copying for repeat I'd like the new task to be:
>
> ,----[ after copy (new copied task) ]
> | ** TODO Weekly Review
> |    SCHEDULED: <2009-03-16 Mon ++1w>
> |    :PROPERTIES:
> |    :RESET_CHECK_BOXES: t
> |    :END:
> |
> |    - [ ] Do this
> |    - [ ] Do that
> |    - [ ] Do another thing
> |
> |    Skip these
> |
> |    - [ ] Used to be Important task 1
> |    - [ ] Used to be Important task 2
> |
> | ** Next task
> `----
>
> The DONE task should probably have the check boxes retained checked,  
> and
> the new copy has the checkboxes cleared.  This seems like it could get
> overly complicated real fast. :(
>
> I could also see this for more involved tasks where you want to
> propagate the subtree too (like my bookkeeping task has lots of steps
> which I keep as separate tasks below the repeated tasks).
>
> Copying the level 2 task (Q2 Accounting) would need to copy all of the
> subtasks in the tree and strip out the :LOGBOOK: drawers from the  
> copy.
>
>
> ------------------------------------------------------------------------
> ** TODO Q2 Accounting						       :PROJECT:
>   DEADLINE: <2009-04-30 Thu +1y>
>   :PROPERTIES:
>   :Effort:   3:00
>   :ORDERED: t
>   :END:
> *** TODO January Accounting [0/17] [0%] 					  :NEXT:
>    :LOGBOOK:...
>    :PROPERTIES:
>    :RESET_CHECK_BOXES: t
>    :END:
>      - [ ] Enter Personal Expenses
>      - [ ] Enter credit card charges
>      - [ ] Balance credit card statement
>      - [ ] Enter Cheques and payments
>      - [ ] Enter Invoices - Receive Payments
>      - [ ] Balance Bank accounts
>      ...
>      - [ ] Get USD value at month end
>      - [ ] Foreign Exchange Adjustments
>      - [ ] Print Reports
>      - [ ] File receipts and reports
>
> *** TODO February Accounting [0/17] [0%]...
> *** TODO Mileage Jan - Mar
>     :PROPERTIES:...
>
> |   | Date        | Car     |  From |    To | Total | Where      |  
> Why                       |
> |---+-------------+---------+-------+-------+-------+------------ 
> +---------------------------|
> | # |             |         |       |       |       |             
> |                           |
>
> *** TODO March Accounting [0/17] [0%]...
> **** TODO Record personal mileage details...
> *** TODO GST [0/3] [0%]
>    :LOGBOOK:...
>    :PROPERTIES:
>    :Effort:   0:10
>    :RESET_CHECK_BOXES: t
>    :END:
>
>   - [ ] Print GST Reports
>   - [ ] File receipts and reports
>   - [ ] File GST Tax Return
>
> ------------------------------------------------------------------------
>
> After writing all this... it would probably be easier just to extract
> out the :LOGBOOK: entries and duplicate the subtree structure for the
> completed tasks.  (ie. the copy is the completed task and just
> reschedule the existing task into the future like we do now)
>
> It might be nice to have a way to have some subtasks in the tree _not_
> be copied.  If you have something to remember for this upcoming  
> repeated
> task you create a subtask for that... but you won't need that in the
> repeated task.
>
> Regards,
> Bernt
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-06 16:49       ` Carsten Dominik
@ 2009-03-07 21:26         ` Bernt Hansen
  2009-03-08 18:25         ` Manuel Hermenegildo
  1 sibling, 0 replies; 12+ messages in thread
From: Bernt Hansen @ 2009-03-07 21:26 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: emacs-orgmode

Carsten Dominik <dominik@science.uva.nl> writes:

> Hi Bernt,

Hi :)

>
> to me this sounds like a pretty convincing argument *not*
> to copy entries...

I think I agree with that.

>
> Another problem is that entries can have IDs, and I
> would like the ID of such an entry to remain the same,
> as a link target.

I don't currently use ids (as far as I know) so I hadn't thought of that
issue.

I'm currently comfortable with the way it works now.  If some better
method comes along I'll try to adapt my workflow.

Thanks,
Bernt

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-06 16:49       ` Carsten Dominik
  2009-03-07 21:26         ` Bernt Hansen
@ 2009-03-08 18:25         ` Manuel Hermenegildo
  2009-03-09  7:41           ` Carsten Dominik
  1 sibling, 1 reply; 12+ messages in thread
From: Manuel Hermenegildo @ 2009-03-08 18:25 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: Bernt Hansen, emacs-orgmode


Sorry for the pause (I was pretty busy last week):

 > Another idea to get this:
 > 
 > Turn on state change notes or at least time stamps.  Either globally,
 > or locally for this entry with a LOGGING property:
 > 
 > ** TODO Check backups
 >      SCHEDULED: <2009-03-05 Thu 11:00 +2d>
 >     :PROPERTIES:
 >     :LOGGING: DONE(!)
 >     :END:
 > 
 > (yes, scheduled, thanks Bernt...)
 > Then each time you go through the DONE state, a time stamp
 > will be recorded like this (I am assuming that you have
 > org-log-into-drawer set...)
 > 
 > ** TODO Check backups
 >     SCHEDULED: <2009-04-28 Tue 11:00 +2d>
 >     :LOGBOOK:
 >     - State "DONE"       from "TODO"       [2009-03-04 Wed 14:25]
 >     - State "DONE"       from "TODO"       [2009-03-02 Mon 14:25]
 >     - State "DONE"       from "TODO"       [2009-02-28 Sat 14:25]
 >     - State "DONE"       from "TODO"       [2009-02-26 Thu 14:25]
 >     :END:
 >     :PROPERTIES:
 >     :LOGGING:  DONE(!)
 > 
 > In the agenda, if you press `C-u l', these state notes
 > will become visible.
 > 
 > I believe this will take care of it, right??

Yes, this is much closer than what one would like.  And having those
"done states" together could be useful. 

However, I have to say that though that after trying to adapt to these
settings I cannot bend my mind to find the behavior comfortable,
specially comparing to how normal tasks work. 

For me it is confusing that when I do "t" on such a task it goes to
"DONE" as I would expect (i.e., like a normal TODO task) but when I
refresh the agenda it disappears (unlike normal DONE tasks, at least
with my settings --I use archiving to make done tasks disappear and
"v" to toggle viewing archived tasks).  Actually, I think it goes to
DONE only for the first repeat, for the following repeats it stays as
TODO, at least with my settings.  

I guess I can use org-agenda-skip-scheduled-if-done to get the
non-repeating tasks to disappear also when marked as done (so that
there is more orthogonality) but, again, it will only work if I
remember to use "SCHEDULED" for them, and, also, I do not want them to
disappear yet! ;-)

Also, I feel I have to remember too many things for, say, a simple
weekly meeting: a) putting SCHEDULED, b) setting the properties, c)
making sure org-log-into-drawer is set, etc.  Ideally any simple TODO
entry with a repeating timestamp should behave well when marked as
done, right?

 > to me this sounds like a pretty convincing argument *not*
 > to copy entries...

Yes, I guess this is a problem (although in my case all repeating
entries --which are regular meetings, classes, birthdays, etc.-- are
typically one liners so it would not make a difference if they were
copied...). 

Sorry to insist, but I still think copying the tasks would produce a
more orthogonal behavior. Perhaps it could be made optional?

Man

-- 
-------------------------------------------------------------------------------
 Manuel Hermenegildo                     | Prof., C.S.Dept., T.U. Madrid (UPM)
 Director, IMDEA-Software and CLIP Group | +34-91-336-7435 (W) -352-4819 (Fax)
-------------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
  2009-03-08 18:25         ` Manuel Hermenegildo
@ 2009-03-09  7:41           ` Carsten Dominik
       [not found]             ` <18870.13851.387945.968246@clip.dia.fi.upm.es>
  0 siblings, 1 reply; 12+ messages in thread
From: Carsten Dominik @ 2009-03-09  7:41 UTC (permalink / raw)
  To: Manuel Hermenegildo; +Cc: Bernt Hansen, emacs-orgmode


Hi Manuel,

first of all, you don't need to take notes into the LOGBOOK drawer.
If that is off, notes will be just added after the heading.

Second, setting the properties for logstate or lognotestate
is actually not necessary at all, my mistake.
It is sufficient to have org-log-repeat set, and the default
is `time', so you should automatically get a time stamp each
time an entry repeats.  Don't you?

About the behavior in the agenda, I think it is already
very nice of me :-) to show you the task as DONE until the
next refresh - because in the original buffer, is is actually
already TODO again.

If you always want to see state changes when you press `l' in the
agenda (i.e. by default, without pressing `C-u l'), then you
can configure the variable org-agenda-log-mode-items to include
also the symbol `state'.

For the copying, I think we really need to make a difference
between a single task that repeats, and many similar tasks,
which is what you are talking about.

A single task that repeats is the current behavior, and I still
believe it makes sense this way.

Why, if you want to have many tasks instead of one, don't
you just create many directly, with different dates.  A keyboard
macro would work for this, or a little function that does the
copying and time shifting.

I may make a function that copies a task N times
with a certain date shift.

The more I think about the automatic copying when DONE, the less
sense it makes to me, I am afraid.

- Carsten


On Mar 8, 2009, at 7:25 PM, Manuel Hermenegildo wrote:

>
> Sorry for the pause (I was pretty busy last week):
>
>> Another idea to get this:
>>
>> Turn on state change notes or at least time stamps.  Either globally,
>> or locally for this entry with a LOGGING property:
>>
>> ** TODO Check backups
>>     SCHEDULED: <2009-03-05 Thu 11:00 +2d>
>>    :PROPERTIES:
>>    :LOGGING: DONE(!)
>>    :END:
>>
>> (yes, scheduled, thanks Bernt...)
>> Then each time you go through the DONE state, a time stamp
>> will be recorded like this (I am assuming that you have
>> org-log-into-drawer set...)
>>
>> ** TODO Check backups
>>    SCHEDULED: <2009-04-28 Tue 11:00 +2d>
>>    :LOGBOOK:
>>    - State "DONE"       from "TODO"       [2009-03-04 Wed 14:25]
>>    - State "DONE"       from "TODO"       [2009-03-02 Mon 14:25]
>>    - State "DONE"       from "TODO"       [2009-02-28 Sat 14:25]
>>    - State "DONE"       from "TODO"       [2009-02-26 Thu 14:25]
>>    :END:
>>    :PROPERTIES:
>>    :LOGGING:  DONE(!)
>>
>> In the agenda, if you press `C-u l', these state notes
>> will become visible.
>>
>> I believe this will take care of it, right??
>
> Yes, this is much closer than what one would like.  And having those
> "done states" together could be useful.
>
> However, I have to say that though that after trying to adapt to these
> settings I cannot bend my mind to find the behavior comfortable,
> specially comparing to how normal tasks work.
>
> For me it is confusing that when I do "t" on such a task it goes to
> "DONE" as I would expect (i.e., like a normal TODO task) but when I
> refresh the agenda it disappears (unlike normal DONE tasks, at least
> with my settings --I use archiving to make done tasks disappear and
> "v" to toggle viewing archived tasks).  Actually, I think it goes to
> DONE only for the first repeat, for the following repeats it stays as
> TODO, at least with my settings.
>
> I guess I can use org-agenda-skip-scheduled-if-done to get the
> non-repeating tasks to disappear also when marked as done (so that
> there is more orthogonality) but, again, it will only work if I
> remember to use "SCHEDULED" for them, and, also, I do not want them to
> disappear yet! ;-)
>
> Also, I feel I have to remember too many things for, say, a simple
> weekly meeting: a) putting SCHEDULED, b) setting the properties, c)
> making sure org-log-into-drawer is set, etc.  Ideally any simple TODO
> entry with a repeating timestamp should behave well when marked as
> done, right?
>
>> to me this sounds like a pretty convincing argument *not*
>> to copy entries...
>
> Yes, I guess this is a problem (although in my case all repeating
> entries --which are regular meetings, classes, birthdays, etc.-- are
> typically one liners so it would not make a difference if they were
> copied...).
>
> Sorry to insist, but I still think copying the tasks would produce a
> more orthogonal behavior. Perhaps it could be made optional?
>
> Man
>
> --  
> -------------------------------------------------------------------------------
> Manuel Hermenegildo                     | Prof., C.S.Dept., T.U.  
> Madrid (UPM)
> Director, IMDEA-Software and CLIP Group | +34-91-336-7435 (W)  
> -352-4819 (Fax)
> -------------------------------------------------------------------------------
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: done-ing a repeating scheduled task now inserts closed timestamp?
       [not found]             ` <18870.13851.387945.968246@clip.dia.fi.upm.es>
@ 2009-03-11 14:15               ` Carsten Dominik
  0 siblings, 0 replies; 12+ messages in thread
From: Carsten Dominik @ 2009-03-11 14:15 UTC (permalink / raw)
  To: Manuel Hermenegildo; +Cc: Bernt Hansen, emacs-orgmode


On Mar 10, 2009, at 10:42 AM, Manuel Hermenegildo wrote:

>
> Hi Carten,
>
> OK, OK, I will try again to bend my mind around the current
> behavior. ;-)
>
>> Why, if you want to have many tasks instead of one, don't
>> you just create many directly, with different dates.  A keyboard
>> macro would work for this, or a little function that does the
>> copying and time shifting.
>>
>> I may make a function that copies a task N times
>> with a certain date shift.
>
> You have a point. Such a function would indeed be great for, e.g.,
> scheduling classes, where one can, after having created N tasks,
> annotate each with what will be taught, eliminate those that fall on
> holidays, etc.
>
> Perhaps the function should take a parameter N (C-u N ...) and, when
> called with the cursor over a repeating task, unfold it N times on
> demand into N non-repeating tasks and a new repeating task starting at
> the date after the last copy.

This command is now available, org-clone-subtree-with-time-shift,  
bound to
`C-c C-x c'.

Please read the docstring of the command for details.

- Carsten

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2009-03-11 14:16 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-03  1:29 done-ing a repeating scheduled task now inserts closed timestamp? Samuel Wales
2009-03-03  8:56 ` Manuel Hermenegildo
2009-03-04 13:03   ` Carsten Dominik
2009-03-04 14:26     ` Bernt Hansen
2009-03-06 16:49       ` Carsten Dominik
2009-03-07 21:26         ` Bernt Hansen
2009-03-08 18:25         ` Manuel Hermenegildo
2009-03-09  7:41           ` Carsten Dominik
     [not found]             ` <18870.13851.387945.968246@clip.dia.fi.upm.es>
2009-03-11 14:15               ` Carsten Dominik
2009-03-04 13:15   ` Bernt Hansen
2009-03-04 13:30   ` Carsten Dominik
2009-03-04  6:17 ` 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).