* Recurring tasks and arbitrary properties
@ 2017-01-21 19:06 Michael Welle
2017-01-22 13:09 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Michael Welle @ 2017-01-21 19:06 UTC (permalink / raw)
To: emacs-orgmode
Hello,
a task like this behaves like a recurring task, i.e. if I set the task
state to DONE it is automatically switched back to TODO. Is that the
intended behaviour?
* TODO task1
:PROPERTIES:
:FOO: <2017-03-12 Sun ++1w>
:END:
Regards
hmw
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Recurring tasks and arbitrary properties
2017-01-21 19:06 Recurring tasks and arbitrary properties Michael Welle
@ 2017-01-22 13:09 ` Nicolas Goaziou
2017-01-22 13:17 ` Michael Welle
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2017-01-22 13:09 UTC (permalink / raw)
To: Michael Welle; +Cc: emacs-orgmode
Hello,
Michael Welle <mwe012008@gmx.net> writes:
> a task like this behaves like a recurring task, i.e. if I set the task
> state to DONE it is automatically switched back to TODO. Is that the
> intended behaviour?
>
> * TODO task1
> :PROPERTIES:
> :FOO: <2017-03-12 Sun ++1w>
> :END:
Historically, location of regular (i.e., non scheduled non deadline)
active time stamps in an entry has always been sloppy. In particular,
Org Agenda happily processes active time stamps in properties drawers.
IMO, this shouldn't be the case, but I can see a use for it and doing
otherwise would probably break a lot of documents for little benefit.
So, yes, this is the intended behaviour.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Recurring tasks and arbitrary properties
2017-01-22 13:09 ` Nicolas Goaziou
@ 2017-01-22 13:17 ` Michael Welle
2017-01-22 13:20 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Michael Welle @ 2017-01-22 13:17 UTC (permalink / raw)
To: emacs-orgmode
Hello,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> Michael Welle <mwe012008@gmx.net> writes:
>
>> a task like this behaves like a recurring task, i.e. if I set the task
>> state to DONE it is automatically switched back to TODO. Is that the
>> intended behaviour?
>>
>> * TODO task1
>> :PROPERTIES:
>> :FOO: <2017-03-12 Sun ++1w>
>> :END:
>
> Historically, location of regular (i.e., non scheduled non deadline)
> active time stamps in an entry has always been sloppy. In particular,
> Org Agenda happily processes active time stamps in properties drawers.
>
> IMO, this shouldn't be the case, but I can see a use for it and doing
> otherwise would probably break a lot of documents for little benefit.
>
> So, yes, this is the intended behaviour.
hmm, what's a good way to work around that? Removing, let's say, the
brackets before storing that value?
Regards
hmw
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Recurring tasks and arbitrary properties
2017-01-22 13:17 ` Michael Welle
@ 2017-01-22 13:20 ` Nicolas Goaziou
2017-01-22 13:27 ` Michael Welle
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2017-01-22 13:20 UTC (permalink / raw)
To: Michael Welle; +Cc: emacs-orgmode
Michael Welle <mwe012008@gmx.net> writes:
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>> Michael Welle <mwe012008@gmx.net> writes:
>>
>>> a task like this behaves like a recurring task, i.e. if I set the task
>>> state to DONE it is automatically switched back to TODO. Is that the
>>> intended behaviour?
>>>
>>> * TODO task1
>>> :PROPERTIES:
>>> :FOO: <2017-03-12 Sun ++1w>
>>> :END:
>>
>> Historically, location of regular (i.e., non scheduled non deadline)
>> active time stamps in an entry has always been sloppy. In particular,
>> Org Agenda happily processes active time stamps in properties drawers.
>>
>> IMO, this shouldn't be the case, but I can see a use for it and doing
>> otherwise would probably break a lot of documents for little benefit.
>>
>> So, yes, this is the intended behaviour.
>
> hmm, what's a good way to work around that? Removing, let's say, the
> brackets before storing that value?
Couldn't you use inactive time stamps?
Regards,
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Recurring tasks and arbitrary properties
2017-01-22 13:20 ` Nicolas Goaziou
@ 2017-01-22 13:27 ` Michael Welle
2017-01-22 13:37 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Michael Welle @ 2017-01-22 13:27 UTC (permalink / raw)
To: emacs-orgmode
Hello,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Michael Welle <mwe012008@gmx.net> writes:
>
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>>
>>> Michael Welle <mwe012008@gmx.net> writes:
>>>
>>>> a task like this behaves like a recurring task, i.e. if I set the task
>>>> state to DONE it is automatically switched back to TODO. Is that the
>>>> intended behaviour?
>>>>
>>>> * TODO task1
>>>> :PROPERTIES:
>>>> :FOO: <2017-03-12 Sun ++1w>
>>>> :END:
>>>
>>> Historically, location of regular (i.e., non scheduled non deadline)
>>> active time stamps in an entry has always been sloppy. In particular,
>>> Org Agenda happily processes active time stamps in properties drawers.
>>>
>>> IMO, this shouldn't be the case, but I can see a use for it and doing
>>> otherwise would probably break a lot of documents for little benefit.
>>>
>>> So, yes, this is the intended behaviour.
>>
>> hmm, what's a good way to work around that? Removing, let's say, the
>> brackets before storing that value?
>
> Couldn't you use inactive time stamps?
I want to do something like this:
(defun hmw/org-deactivate-recurring-task ()
"Deactivate a recurring task. The value of the SCHEDULED property is
stored in the property referenced by `hmw/org-scheduled-property-backup',
so it can be restored later. The task's state is set to the value of
`hmw/org-deactivated-recurring-task-state'."
(interactive)
(when (org-entry-is-todo-p)
(save-excursion
(org-back-to-heading t)
(let* ((pom (point-at-bol))
(val (org-entry-get pom "SCHEDULED")))
(if val
(progn
(org-entry-put pom hmw/org-scheduled-property-backup val)
(org-entry-put pom "SCHEDULED" nil)
(org-todo hmw/org-deactivated-recurring-task-state)))))))
I want to 'hide' the value of the SCHEDULED property and later restore
it. I can use inactive time stamps. But that means that I have to change
the value when deactivating the task and again, later when I activate
the task again. But it would have been nicer without doing so ;).
Thanks for your help.
Regards
hmw
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Recurring tasks and arbitrary properties
2017-01-22 13:27 ` Michael Welle
@ 2017-01-22 13:37 ` Nicolas Goaziou
2017-01-22 13:56 ` Michael Welle
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2017-01-22 13:37 UTC (permalink / raw)
To: Michael Welle; +Cc: emacs-orgmode
Michael Welle <mwe012008@gmx.net> writes:
> I want to 'hide' the value of the SCHEDULED property and later restore
> it. I can use inactive time stamps. But that means that I have to change
> the value when deactivating the task and again, later when I activate
> the task again. But it would have been nicer without doing so ;).
It depends on what means "later". If it means "right after doing
something to the headline", you could also store the actual time stamp
in the lexical closure of a call-back function, without using a property
drawer.
There is `org-toggle-timestamp-type', too. We could extend it to process
time stamp strings.
Regards,
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Recurring tasks and arbitrary properties
2017-01-22 13:37 ` Nicolas Goaziou
@ 2017-01-22 13:56 ` Michael Welle
2017-01-22 14:01 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Michael Welle @ 2017-01-22 13:56 UTC (permalink / raw)
To: emacs-orgmode
Hello,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Michael Welle <mwe012008@gmx.net> writes:
>
>> I want to 'hide' the value of the SCHEDULED property and later restore
>> it. I can use inactive time stamps. But that means that I have to change
>> the value when deactivating the task and again, later when I activate
>> the task again. But it would have been nicer without doing so ;).
>
> It depends on what means "later". If it means "right after doing
> something to the headline", you could also store the actual time stamp
> in the lexical closure of a call-back function, without using a property
> drawer.
>
> There is `org-toggle-timestamp-type', too. We could extend it to process
> time stamp strings.
later means a lot later ;). Maybe months or even years. My personal use
case is, that I have dozens of recurring tasks. Now I leave the country
for a few months. The tasks only make sense, when I am here. So I want to
disable them and enable them, when I'm back. I can't use
org-cancel-repeater, because that loses the repeater.
There was a question on the ml about disabling recurring tasks many
moons ago. I will incorporate my new knowledge about properties into my
functions and then reply to that question.
Regards
hmw
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Recurring tasks and arbitrary properties
2017-01-22 13:56 ` Michael Welle
@ 2017-01-22 14:01 ` Nicolas Goaziou
2017-01-22 14:08 ` Michael Welle
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2017-01-22 14:01 UTC (permalink / raw)
To: Michael Welle; +Cc: emacs-orgmode
Michael Welle <mwe012008@gmx.net> writes:
> later means a lot later ;). Maybe months or even years. My personal use
> case is, that I have dozens of recurring tasks. Now I leave the country
> for a few months. The tasks only make sense, when I am here. So I want to
> disable them and enable them, when I'm back. I can't use
> org-cancel-repeater, because that loses the repeater.
You can also COMMENT them, or archive them.
Regards,
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Recurring tasks and arbitrary properties
2017-01-22 14:01 ` Nicolas Goaziou
@ 2017-01-22 14:08 ` Michael Welle
0 siblings, 0 replies; 9+ messages in thread
From: Michael Welle @ 2017-01-22 14:08 UTC (permalink / raw)
To: emacs-orgmode
Hello,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Michael Welle <mwe012008@gmx.net> writes:
>
>> later means a lot later ;). Maybe months or even years. My personal use
>> case is, that I have dozens of recurring tasks. Now I leave the country
>> for a few months. The tasks only make sense, when I am here. So I want to
>> disable them and enable them, when I'm back. I can't use
>> org-cancel-repeater, because that loses the repeater.
>
> You can also COMMENT them, or archive them.
yes, but that is so.... I lack the right word ;). I think, the
semantically right way to do it is to set the state of the task to
'Cancelled' or 'Stopped' or something like that. But that doesn't
work as long as the repeater is > 0. That's the reason why I want to
backup the value of the scheduled property and later restore it.
Regards
hmw
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-01-22 14:09 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-21 19:06 Recurring tasks and arbitrary properties Michael Welle
2017-01-22 13:09 ` Nicolas Goaziou
2017-01-22 13:17 ` Michael Welle
2017-01-22 13:20 ` Nicolas Goaziou
2017-01-22 13:27 ` Michael Welle
2017-01-22 13:37 ` Nicolas Goaziou
2017-01-22 13:56 ` Michael Welle
2017-01-22 14:01 ` Nicolas Goaziou
2017-01-22 14:08 ` Michael Welle
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).