Recurring tasks and arbitrary properties

Recurring tasks and arbitrary properties

[Michael Welle]

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

Re: Recurring tasks and arbitrary properties

[Nicolas Goaziou]

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

Re: Recurring tasks and arbitrary properties

[Michael Welle]

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

Re: Recurring tasks and arbitrary properties

[Nicolas Goaziou]

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,

Re: Recurring tasks and arbitrary properties

[Michael Welle]

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

Re: Recurring tasks and arbitrary properties

[Nicolas Goaziou]

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,

Re: Recurring tasks and arbitrary properties

[Michael Welle]

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

Re: Recurring tasks and arbitrary properties

[Nicolas Goaziou]

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,

Re: Recurring tasks and arbitrary properties

[Michael Welle]

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