From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id KOLcGHvkImPmPwEAbAwnHQ (envelope-from ) for ; Thu, 15 Sep 2022 10:38:19 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id eID4GHvkImPvSwEAauVa8A (envelope-from ) for ; Thu, 15 Sep 2022 10:38:19 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 04B8B21796 for ; Thu, 15 Sep 2022 10:38:18 +0200 (CEST) Received: from localhost ([::1]:34228 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYkO1-00051l-UV for larch@yhetil.org; Thu, 15 Sep 2022 04:38:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58882) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYkK0-0004yo-AW for emacs-orgmode@gnu.org; Thu, 15 Sep 2022 04:34:08 -0400 Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:41587) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYkJy-0007Gz-9J for emacs-orgmode@gnu.org; Thu, 15 Sep 2022 04:34:07 -0400 Received: by mail-pl1-x634.google.com with SMTP id p18so17643095plr.8 for ; Thu, 15 Sep 2022 01:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=G8SGw4C5p25cbyxv9789A29FcH4zQdlzH+Ff5pXb93w=; b=V5SNKfxghOPlAO7EBbiUm/ekhjp0ZhYWR7VQRivpd5kBgyX3HnQnGoNUmCZ1ThF6mN qJliO8/BITZNYA1blkXpH1Fh0WSJE4YBINWVtIGEbnaItl+CPG/MSxsnr9kNTdBk5skF naAmvz9eNf6Yb04XuQYefBBApzYYlcvM9goSkv+idiyfQRtLM1d+VlwLLDsHFH1x/IMV islJdotmF2oj6g7AOV9ktX6DANLY823jonzTwNvGJuJXTojmbAkAS8j5qaMzn0PWWhpz 9Bx+46j4CK8MlCIDZ2D01kkXwK2pfrXNEMRj8MCjEguy3cPq7Cx5E7ogfzd5KxcwPGWQ ZadA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=G8SGw4C5p25cbyxv9789A29FcH4zQdlzH+Ff5pXb93w=; b=6WaUuclTeQTPx82HS3rhvQjAC2glK94Crv1x4OpoLgfeiWbqTgDIW+R1j3ihSb1/GM x9ReCb548KYA7Ubv3ylkXcR0x5UXWvR3ZEyO1BZUrmeIeCq0oMjUGsZOiPgiRlwSG4wF XOAZRqhUlPKNqG7VYqNhYt46DBfg+jqkOvIyb0XSz8B1HkqYo1gNpVs55j4R8xhR9juL 3KKte9/E0QN3QeVNTtNAPq4usxZU8aXe+ijutPVKI+4KRw8oJYoM7mIbh0B2hYuD8lno EYuOOddgZtwL4ccSpAfdTXXoF1uuHJORe2CFCaoSHjhxHjxigy3/rwPTJ/+5SWxbFMs6 mYsw== X-Gm-Message-State: ACrzQf2jFkkyThnqzlsweY6Z3qSKUGvnaFNFXoYLtVhmRBdv0d151Ek/ 32J8ttInP6YcsHx4qft/l30= X-Google-Smtp-Source: AMsMyM7cFaYgVIHrVakEOxBisK60COmJOgBixc68zHzNXM6Bntv1QhswWgkF2lldZe7Th9b6RcQQtg== X-Received: by 2002:a17:902:e805:b0:178:230b:57e3 with SMTP id u5-20020a170902e80500b00178230b57e3mr3250749plg.102.1663230844587; Thu, 15 Sep 2022 01:34:04 -0700 (PDT) Received: from localhost ([2409:8970:a81:48f7:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id ik24-20020a170902ab1800b00172eb493487sm12221639plb.167.2022.09.15.01.34.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Sep 2022 01:34:03 -0700 (PDT) From: Ihor Radchenko To: Ignacio Casso 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/)] In-Reply-To: References: <8735ekm5f4.fsf@localhost> Date: Thu, 15 Sep 2022 16:34:57 +0800 Message-ID: <871qsdvxvy.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::634; envelope-from=yantar92@gmail.com; helo=mail-pl1-x634.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1663231099; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=G8SGw4C5p25cbyxv9789A29FcH4zQdlzH+Ff5pXb93w=; b=BhypqkaTuieQmslGpOr5MmbxcszrSXwAD80qxej6ld9ZH0doWeNLzjd6N5YItWxXgHoSJD dz2NOAM6EhLAiPszWc+bbBvNnY76aJSwhh09AS/o9ycgOQjXl1NOEwRoRB6g8g7XyjF6CJ pTS+LZCi88cgMJSzAzQEBYLiZ+YaUoewTraqnL3jo+8v0z8Q039fFTcymKIB+wXxsa+W+l Ddzy9UC8LEAHO7ugUo+hWNwIT45ahoSUelhTICMvoBy/SpOBby+PBnOAmkDVxhAHUBIfF+ 6SXDtB641MqtPS9mPCRnC4H0eoWCSK/C/fiBlPAlxcQczxtQ3icxUU+LnN5YCg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1663231099; a=rsa-sha256; cv=none; b=piVRnGv8E0J9fCFKt7SJpP8gSXyyEUFsDuxnqCejgmxx5zKI2JBATavUVOXFaPcL0GjWi9 76xzPf74N4f4FDO7lW0X5cL1tH5EyvLsUSiESWrxZL3WhLm5k5/XNHIaSDQ/NKZVKh41j4 mPqtDU0FxmjTGCBxiMJ6iOwc3R3EAluFRL6yQi7loqbIMmbfPzw89zG+v2jowr1yxqiBMS dtWfmqeDE1II9p2PpWp/vdIIiiF5mGlmcyH6LfDf7LfekBsFUGay0ferJClYVXuBNnYM6D DjqG4eG3b7KdA7kEYVz3pDCCyITzqkU7VekjT/d1aMjRH3m1xuHhAakJBV4c0g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=V5SNKfxg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.33 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=V5SNKfxg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 04B8B21796 X-Spam-Score: -3.33 X-Migadu-Scanner: scn1.migadu.com X-TUID: pZa3IPMrei25 Sorry for the late reply. Ignacio Casso 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=E2=80=94hierarchy and lists=E2=80=94makes it eas= y 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 =E2=80=98org-enforce-todo-dependencies= =E2=80=99, Org blocks entries from changing state to DONE while they have TODO children that are not DONE. Furthermore, if an entry has a property =E2=80=98ORDERED=E2=80=99, each of its TODO children is blocked until all e= arlier siblings are marked as done. Here is an example: --=20 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