* Possible bug in ordered tasks
@ 2010-06-18 15:42 Robert Goldman
2010-06-25 7:03 ` Carsten Dominik
0 siblings, 1 reply; 9+ messages in thread
From: Robert Goldman @ 2010-06-18 15:42 UTC (permalink / raw)
To: Org Mode
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
I have found what I believe to be a bug in handling ordered subtasks.
Here is the behavior:
I have a top level set of tasks that is ordered.
One of the outline items below the top level set is a grab bag of tasks
that will be performed in parallel. So this task is NOT ordered
(ORDERED: nil).
The problem is that the blocking behavior from ordered tasks seems to be
inherited from the top level task list into the second level of the
outline, even though the ORDERED property at the second level is
explicitly overridden.
I am attaching an org file that displays this issue. To see the
problem, put your cursor on the "Bar" task and attempt to change its
status to DONE.
Cheers,
R
[-- Attachment #2: ordered.org --]
[-- Type: text/plain, Size: 290 bytes --]
* Prepare white paper
:PROPERTIES:
:ORDERED: t
:END:
** TODO Draft outline
** TODO Writing assignments
:PROPERTIES:
:ORDERED: nil
:END:
*** DELEGATED Foo
- State "DELEGATED" from "" [2010-06-18 Fri 10:32] \\
Delegated.
*** TODO Bar
*** TODO Baz
[-- Attachment #3: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Please 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] 9+ messages in thread* Re: Possible bug in ordered tasks 2010-06-18 15:42 Possible bug in ordered tasks Robert Goldman @ 2010-06-25 7:03 ` Carsten Dominik 2010-06-25 13:23 ` Robert Goldman 0 siblings, 1 reply; 9+ messages in thread From: Carsten Dominik @ 2010-06-25 7:03 UTC (permalink / raw) To: rpgoldman; +Cc: Org Mode Hi Robert, On Jun 18, 2010, at 5:42 PM, Robert Goldman wrote: > I have found what I believe to be a bug in handling ordered subtasks. > Here is the behavior: > > I have a top level set of tasks that is ordered. > > One of the outline items below the top level set is a grab bag of > tasks > that will be performed in parallel. So this task is NOT ordered > (ORDERED: nil). > > The problem is that the blocking behavior from ordered tasks seems > to be > inherited from the top level task list into the second level of the > outline, even though the ORDERED property at the second level is > explicitly overridden. > > I am attaching an org file that displays this issue. To see the > problem, put your cursor on the "Bar" task and attempt to change its > status to DONE. The problem here is that the value of the ORDERED property is the string "nil", and that is of course not nil! I have introduced a special case to have "nil" interpreted as nil here, because your use case makes a lot of sense. Thanks! - Carsten ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible bug in ordered tasks 2010-06-25 7:03 ` Carsten Dominik @ 2010-06-25 13:23 ` Robert Goldman 2010-06-25 14:12 ` Carsten Dominik 0 siblings, 1 reply; 9+ messages in thread From: Robert Goldman @ 2010-06-25 13:23 UTC (permalink / raw) To: Carsten Dominik; +Cc: Org Mode On 6/25/10 Jun 25 -2:03 AM, Carsten Dominik wrote: > Hi Robert, > > On Jun 18, 2010, at 5:42 PM, Robert Goldman wrote: > >> I have found what I believe to be a bug in handling ordered subtasks. >> Here is the behavior: >> >> I have a top level set of tasks that is ordered. >> >> One of the outline items below the top level set is a grab bag of tasks >> that will be performed in parallel. So this task is NOT ordered >> (ORDERED: nil). >> >> The problem is that the blocking behavior from ordered tasks seems to be >> inherited from the top level task list into the second level of the >> outline, even though the ORDERED property at the second level is >> explicitly overridden. >> >> I am attaching an org file that displays this issue. To see the >> problem, put your cursor on the "Bar" task and attempt to change its >> status to DONE. > > The problem here is that the value of the ORDERED property is the string > "nil", and that is of course not nil! > > I have introduced a special case to have "nil" interpreted as nil here, > because your use case makes a lot of sense. Oh, dear. That makes perfect sense, now that I think of it. Question: what is the proper way to get a NIL into a property? Are we to use () instead of "nil"? Or are property values always interpreted as strings? Apologies in advance if this is a stupid question! thanks! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible bug in ordered tasks 2010-06-25 13:23 ` Robert Goldman @ 2010-06-25 14:12 ` Carsten Dominik 2010-06-25 14:48 ` Robert Goldman 2010-06-25 18:55 ` Bernt Hansen 0 siblings, 2 replies; 9+ messages in thread From: Carsten Dominik @ 2010-06-25 14:12 UTC (permalink / raw) To: rpgoldman; +Cc: Org Mode On Jun 25, 2010, at 3:23 PM, Robert Goldman wrote: > On 6/25/10 Jun 25 -2:03 AM, Carsten Dominik wrote: >> Hi Robert, >> >> On Jun 18, 2010, at 5:42 PM, Robert Goldman wrote: >> >>> I have found what I believe to be a bug in handling ordered >>> subtasks. >>> Here is the behavior: >>> >>> I have a top level set of tasks that is ordered. >>> >>> One of the outline items below the top level set is a grab bag of >>> tasks >>> that will be performed in parallel. So this task is NOT ordered >>> (ORDERED: nil). >>> >>> The problem is that the blocking behavior from ordered tasks seems >>> to be >>> inherited from the top level task list into the second level of the >>> outline, even though the ORDERED property at the second level is >>> explicitly overridden. >>> >>> I am attaching an org file that displays this issue. To see the >>> problem, put your cursor on the "Bar" task and attempt to change its >>> status to DONE. >> >> The problem here is that the value of the ORDERED property is the >> string >> "nil", and that is of course not nil! >> >> I have introduced a special case to have "nil" interpreted as nil >> here, >> because your use case makes a lot of sense. > > Oh, dear. That makes perfect sense, now that I think of it. > > Question: what is the proper way to get a NIL into a property? Are > we > to use () instead of "nil"? Or are property values always interpreted > as strings? > > Apologies in advance if this is a stupid question! Not a stupid question at all. There is no way, currently. Property values are string - the only way to make org-entry-get return nil is to not have the property defined at all. - Carsten ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible bug in ordered tasks 2010-06-25 14:12 ` Carsten Dominik @ 2010-06-25 14:48 ` Robert Goldman 2010-06-25 16:21 ` Carsten Dominik 2010-06-25 18:55 ` Bernt Hansen 1 sibling, 1 reply; 9+ messages in thread From: Robert Goldman @ 2010-06-25 14:48 UTC (permalink / raw) To: Carsten Dominik; +Cc: Org Mode On 6/25/10 Jun 25 -9:12 AM, Carsten Dominik wrote: > > On Jun 25, 2010, at 3:23 PM, Robert Goldman wrote: > >> On 6/25/10 Jun 25 -2:03 AM, Carsten Dominik wrote: >>> Hi Robert, >>> >>> On Jun 18, 2010, at 5:42 PM, Robert Goldman wrote: >>> >>>> I have found what I believe to be a bug in handling ordered subtasks. >>>> Here is the behavior: >>>> >>>> I have a top level set of tasks that is ordered. >>>> >>>> One of the outline items below the top level set is a grab bag of tasks >>>> that will be performed in parallel. So this task is NOT ordered >>>> (ORDERED: nil). >>>> >>>> The problem is that the blocking behavior from ordered tasks seems >>>> to be >>>> inherited from the top level task list into the second level of the >>>> outline, even though the ORDERED property at the second level is >>>> explicitly overridden. >>>> >>>> I am attaching an org file that displays this issue. To see the >>>> problem, put your cursor on the "Bar" task and attempt to change its >>>> status to DONE. >>> >>> The problem here is that the value of the ORDERED property is the string >>> "nil", and that is of course not nil! >>> >>> I have introduced a special case to have "nil" interpreted as nil here, >>> because your use case makes a lot of sense. >> >> Oh, dear. That makes perfect sense, now that I think of it. >> >> Question: what is the proper way to get a NIL into a property? Are we >> to use () instead of "nil"? Or are property values always interpreted >> as strings? >> >> Apologies in advance if this is a stupid question! > > Not a stupid question at all. > > There is no way, currently. Property values are string - the only way > to make > org-entry-get return nil is to not have the property defined at all. OK, and there's no problem with this /except/ in cases where one wishes to override inheritance, right? I.e., you never need to specify nil at the top level; it's only when you need to cancel a value that you are inheriting.... best, r ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible bug in ordered tasks 2010-06-25 14:48 ` Robert Goldman @ 2010-06-25 16:21 ` Carsten Dominik 0 siblings, 0 replies; 9+ messages in thread From: Carsten Dominik @ 2010-06-25 16:21 UTC (permalink / raw) To: rpgoldman; +Cc: Org Mode On Jun 25, 2010, at 4:48 PM, Robert Goldman wrote: > On 6/25/10 Jun 25 -9:12 AM, Carsten Dominik wrote: >> >> On Jun 25, 2010, at 3:23 PM, Robert Goldman wrote: >> >>> On 6/25/10 Jun 25 -2:03 AM, Carsten Dominik wrote: >>>> Hi Robert, >>>> >>>> On Jun 18, 2010, at 5:42 PM, Robert Goldman wrote: >>>> >>>>> I have found what I believe to be a bug in handling ordered >>>>> subtasks. >>>>> Here is the behavior: >>>>> >>>>> I have a top level set of tasks that is ordered. >>>>> >>>>> One of the outline items below the top level set is a grab bag >>>>> of tasks >>>>> that will be performed in parallel. So this task is NOT ordered >>>>> (ORDERED: nil). >>>>> >>>>> The problem is that the blocking behavior from ordered tasks seems >>>>> to be >>>>> inherited from the top level task list into the second level of >>>>> the >>>>> outline, even though the ORDERED property at the second level is >>>>> explicitly overridden. >>>>> >>>>> I am attaching an org file that displays this issue. To see the >>>>> problem, put your cursor on the "Bar" task and attempt to change >>>>> its >>>>> status to DONE. >>>> >>>> The problem here is that the value of the ORDERED property is the >>>> string >>>> "nil", and that is of course not nil! >>>> >>>> I have introduced a special case to have "nil" interpreted as nil >>>> here, >>>> because your use case makes a lot of sense. >>> >>> Oh, dear. That makes perfect sense, now that I think of it. >>> >>> Question: what is the proper way to get a NIL into a property? >>> Are we >>> to use () instead of "nil"? Or are property values always >>> interpreted >>> as strings? >>> >>> Apologies in advance if this is a stupid question! >> >> Not a stupid question at all. >> >> There is no way, currently. Property values are string - the only >> way >> to make >> org-entry-get return nil is to not have the property defined at all. > > OK, and there's no problem with this /except/ in cases where one > wishes > to override inheritance, right? I.e., you never need to specify nil > at > the top level; it's only when you need to cancel a value that you are > inheriting.... Exactly. Cheers - Carsten ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible bug in ordered tasks 2010-06-25 14:12 ` Carsten Dominik 2010-06-25 14:48 ` Robert Goldman @ 2010-06-25 18:55 ` Bernt Hansen 2010-06-26 5:55 ` Carsten Dominik 1 sibling, 1 reply; 9+ messages in thread From: Bernt Hansen @ 2010-06-25 18:55 UTC (permalink / raw) To: Carsten Dominik; +Cc: Org Mode, rpgoldman Carsten Dominik <carsten.dominik@gmail.com> writes: > On Jun 25, 2010, at 3:23 PM, Robert Goldman wrote: > >> Question: what is the proper way to get a NIL into a property? Are >> we >> to use () instead of "nil"? Or are property values always interpreted >> as strings? >> >> Apologies in advance if this is a stupid question! > > Not a stupid question at all. > > There is no way, currently. Property values are string - the only > way to make > org-entry-get return nil is to not have the property defined at all. I've wanted a similar thing in the past for the LOGGING property where the parent task has special logging set via the LOGGING property but I want to undo that for some of the child tasks so they use the default logging setup. Having a way to undefine a property would be good in general I think. -Bernt ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible bug in ordered tasks 2010-06-25 18:55 ` Bernt Hansen @ 2010-06-26 5:55 ` Carsten Dominik 2010-06-26 11:34 ` Bernt Hansen 0 siblings, 1 reply; 9+ messages in thread From: Carsten Dominik @ 2010-06-26 5:55 UTC (permalink / raw) To: Bernt Hansen; +Cc: Org Mode, rpgoldman On Jun 25, 2010, at 8:55 PM, Bernt Hansen wrote: > Carsten Dominik <carsten.dominik@gmail.com> writes: > >> On Jun 25, 2010, at 3:23 PM, Robert Goldman wrote: >> >>> Question: what is the proper way to get a NIL into a property? Are >>> we >>> to use () instead of "nil"? Or are property values always >>> interpreted >>> as strings? >>> >>> Apologies in advance if this is a stupid question! >> >> Not a stupid question at all. >> >> There is no way, currently. Property values are string - the only >> way to make >> org-entry-get return nil is to not have the property defined at all. > > I've wanted a similar thing in the past for the LOGGING property where > the parent task has special logging set via the LOGGING property but I > want to undo that for some of the child tasks so they use the default > logging setup. > > Having a way to undefine a property would be good in general I think. This does now work, the property value "nil" will now be interpreted as explicit undefine of a property. - Carsten ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible bug in ordered tasks 2010-06-26 5:55 ` Carsten Dominik @ 2010-06-26 11:34 ` Bernt Hansen 0 siblings, 0 replies; 9+ messages in thread From: Bernt Hansen @ 2010-06-26 11:34 UTC (permalink / raw) To: Carsten Dominik; +Cc: Org Mode, rpgoldman Carsten Dominik <carsten.dominik@gmail.com> writes: > On Jun 25, 2010, at 8:55 PM, Bernt Hansen wrote: > >> Having a way to undefine a property would be good in general I think. > > This does now work, the property value "nil" will now be interpreted as > explicit undefine of a property. Thanks!! -Bernt ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-06-26 11:34 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-06-18 15:42 Possible bug in ordered tasks Robert Goldman 2010-06-25 7:03 ` Carsten Dominik 2010-06-25 13:23 ` Robert Goldman 2010-06-25 14:12 ` Carsten Dominik 2010-06-25 14:48 ` Robert Goldman 2010-06-25 16:21 ` Carsten Dominik 2010-06-25 18:55 ` Bernt Hansen 2010-06-26 5:55 ` Carsten Dominik 2010-06-26 11:34 ` Bernt Hansen
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.