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
_______________________________________________
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
