* 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 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-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
[parent not found: <18870.13851.387945.968246@clip.dia.fi.upm.es>]
* 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
* 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-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
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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.