emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Ignacio Casso <ignaciocasso@hotmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] Inconsistent behaviour of TODO + COMMENT + TODO dependencies + agenda? [9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)]
Date: Thu, 15 Sep 2022 16:34:57 +0800	[thread overview]
Message-ID: <871qsdvxvy.fsf@localhost> (raw)
In-Reply-To: <AM8P250MB019891FCD0B4CB9A93DDEF52C6609@AM8P250MB0198.EURP250.PROD.OUTLOOK.COM>

Sorry for the late reply.

Ignacio Casso <ignaciocasso@hotmail.com> writes:

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

This is indeed inconsistent. I suspect that the main reason is an
omission in the code when a single re-search-forward is used to check if
there are undone descendant tasks. If not and the code deliberately
checks things not mentioned in the manual, we may need to look further
and dig into the mailing list/git logs.

> 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 think that they are mostly clarified in "5.2.7 TODO dependencies"
section of the manual, except slightly confusing passage about subtasks:

5.2.7 TODO dependencies ::

The structure of Org files—hierarchy and lists—makes it easy to define
TODO dependencies.  Usually, a parent TODO task should not be marked as
done until all TODO subtasks, or children tasks, are marked as done.
                    ^^^^^^^^
Sometimes there is a logical sequence to (sub)tasks, so that one subtask
cannot be acted upon before all siblings above it have been marked as
done.  If you customize the variable ‘org-enforce-todo-dependencies’,
Org blocks entries from changing state to DONE while they have TODO
children that are not DONE.  Furthermore, if an entry has a property
‘ORDERED’, each of its TODO children is blocked until all earlier
siblings are marked as done.  Here is an example:

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92


      reply	other threads:[~2022-09-15  8:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09 12:19 [BUG] Inconsistent behaviour of TODO + COMMENT + TODO dependencies + agenda? [9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)] Ignacio Casso
2022-07-29 13:09 ` Ihor Radchenko
2022-08-07 20:49   ` Ignacio Casso
2022-09-15  8:34     ` Ihor Radchenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871qsdvxvy.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ignaciocasso@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).