>> P.D: Just when I was going to send this I tried to investigate it a
>> little bit more to not waste anyone's time, and I found the variable
>> 'org-agenda-skip-comment-trees', which defaults to 't'. So now I see that
>> if it is set to 'nil' it would not be inconsistent to me anymore, but I
>> still think that the default behaviour is inconsistent, or at least
>> unintituive for newcomers, and that maybe a corresponding variable like
>> 'org-dependencies-skip-comment-trees' might be needed.
>
> This makes sense. The new variable should default to the old behaviour -
> we do not want to break existing Org files relying on it.
>
> Patches are welcome!
I was going to write one, but I have found further inconsistencies and
incomplete documentation and I think we should clearly define first how
we want dependencies to behave. According to the Org Mode documentation
and the docstrings of `org-enforce-todo-dependencies' and
`org-block-todo-from-children-or-siblings-or-parent', tasks are blocked
when:
1. The task has undone children tasks.
2. A task has a parent with the property :ORDERED:, and there
are undone sibling tasks prior to the current task
3. The parent of the task is blocked because it has siblings that should
be done first, or is child of a blocked grandparent TODO entry."
But they are actually blocked when:
1. The task has undone DESCENDANT tasks (i.e., undone children of
children also block)
2. A task has a parent with the property :ORDERED:, and there
are sibling tasks prior to the current task which are undone OR
HAVE UNDONE DESCENDANTS
3. The parent of the task is blocked because it has siblings that should
be done first, or is child of a blocked grandparent TODO entry. BUT
THE TASK IS NOT BLOCKED E.G., IF ITS GRANDPARENT IS BLOCKED AND IS
PARENT IS DONE OR HAS NO TODO STATE.
So my other issues are:
- Remarks in upper case in points 1 and 2 should be clarified in the
documentation and docstrings, if that is actually the desired
behaviour and not a bug. Otherwise, they should be fixed. I can do
that in the same patch.
- I also find inconsistent that in points 1 and 2 not only parents and
children are considered for blocking but also further ancestors and
descendants, but in point three only a direct chain of blocked parents
is considered.
What do you think about them? I'll start writing the original patch for
now, let me know if you want me to address any of those points too while
I'm at it.
Ignacio
