From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id mGj9GhPe1V9SOQAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 09:25:39 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id KBnLFhPe1V93UQAA1q6Kng (envelope-from ) for ; Sun, 13 Dec 2020 09:25:39 +0000 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 DDB98940355 for ; Sun, 13 Dec 2020 09:25:38 +0000 (UTC) Received: from localhost ([::1]:52926 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koNdJ-0005o6-TR for larch@yhetil.org; Sun, 13 Dec 2020 04:25:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43670) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koNck-0005nP-BA for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 04:25:02 -0500 Received: from mail-pj1-x1032.google.com ([2607:f8b0:4864:20::1032]:52643) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koNci-0004WY-Gc for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 04:25:02 -0500 Received: by mail-pj1-x1032.google.com with SMTP id v1so4606764pjr.2 for ; Sun, 13 Dec 2020 01:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=S5MmppL/KVTAunAd7Du0rM7LqV1xSzoQpxO3/aX5Ey0=; b=Lbtb7jMDyVDgFRxvewUj+iIvyf6PET4o7+JAY+9UT0ND7ph3e/qb6zEeArlccqWJz4 FqH3HzhlN8Itg8NNtjzSlJBfoYHbEV+QWwuxH1nF5D1WxvOKj4zHwavGd1V9aEK5Wbcs tK9KtPGMUFdU/pYiAi2ZTFcLwFr24/S/smaWQr5cVMAYaMsULnWpk9wMEC9g3KZptyYn 9su6Y3jFJ86OoqzNAcPXZpHBjGKQ/wRtFKba6TvcfaYsPRGDpWyme/ON/9lH6lRwhRu5 9XsJm8dLmRzjkgOYnSBp/kgfLPOIHoiq6O+c4oDMNNhjuy/KKFXJjUo1FECRo5t8lmfH SSvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=S5MmppL/KVTAunAd7Du0rM7LqV1xSzoQpxO3/aX5Ey0=; b=Lv9mfjUQCSowNdQ1tiNe//C0fwiiXI0kQywUJ0nsdzrqw0pH2arcAduFtEKjEyfq34 p+zIYPxM9i3g4sogiXHNHdmIzht7tXySre+tQA2WvHI7CBLOURRPQSj7q83z+NgSI4mL TIBAn+XWuaPHtdppmbikjOQiCYJWJBXD7//TzfGARWDvit2vw7ebHHmr84DVuPS9cpD4 gIEHuqyvOGzcNZv3m8Heb3Ss0wh31hp9du5z5V4oQY1zf2KrYPm0W13KRgCI1UT8qUQQ pHwX5eejYQTaK5cmJN8mmuGT1oL1V9GhbLt7aPdZvnDbfIn9mOFh88BE+/RfzB5mOf2c zuaw== X-Gm-Message-State: AOAM530LM3tb6zYGfA/D/qjtoDVcQs+OPmD5onRm2Qd8GBQVv+0ZC7zM YqtugGcLMpDbgWx4aE6ZPEM= X-Google-Smtp-Source: ABdhPJypUfkVMibpXKq005IaUMhS15w/2khUGqThgmyU5dx76RfAP2Hb3ZPh9dHX6d1dkwPR9y3RLQ== X-Received: by 2002:a17:902:59d0:b029:da:69a8:11a8 with SMTP id d16-20020a17090259d0b02900da69a811a8mr18130564plj.63.1607851498949; Sun, 13 Dec 2020 01:24:58 -0800 (PST) Received: from localhost ([50.7.251.66]) by smtp.gmail.com with ESMTPSA id m30sm9719401pgb.26.2020.12.13.01.24.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Dec 2020 01:24:57 -0800 (PST) From: Ihor Radchenko To: Jean Louis , TRS-80 Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options In-Reply-To: References: <87im9nri5l.fsf@kyleam.com> <7330ab95c71d5d41d7fa6faffeaf300f@isnotmyreal.name> <20201211082501.GA18715@tuxteam.de> <871rfwctb2.fsf@localhost> Date: Sun, 13 Dec 2020 17:28:48 +0800 Message-ID: <87y2i23vhr.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::1032; envelope-from=yantar92@gmail.com; helo=mail-pj1-x1032.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.50 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=Lbtb7jMD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: DDB98940355 X-Spam-Score: -2.50 X-Migadu-Scanner: scn1.migadu.com X-TUID: J+qXjH/b+O7D Jean Louis writes: > Org files I have always found useful for project and plan documents > preparation, in particular LaTeX and PDF export. As that way I get > better readability on screen and good printed document. > > None of such projects and plans need be marked with TODO as its nature > is that it is action plan, all items are actionable items. We print a > project and execute it. People report on project steps by email.=20 I disagree. Or rather it depends on workflow: In the process of writing a plan or document there is sometimes an urge to fix small details instead of finishing the first draft and moving to more fine-grained edits afterwards. One way around this urge is quickly inserting an inline todo item and continuing to write (another way is writing on paper, but one would need to spend extra time re-typing the hand writing later). If the document text has inline todo items, it could be useful to mark the top-level headline todo as well, simply to remind about any ideas postponed during the writing. Such headline cannot be switched to done if org enforced todo dependencies. > There is no need to write TODO anywhere as printed file cannot be > changed easily to DONE, it is redundant marking action list item on > the paper with anything but heavy check mark =E2=9C=94 with initals and d= ate > and time when it was completed. Using it for printed projects is not > same as using computer. In general it makes more practical sense to > export Org files to paper and focus on what has to be done instead on > focusing on decorating Org properties or tags as it wastes time. Todo keywords don't have to be included into exported version of the document. >> Unless I am badly mistaken, I think this is only true when >> org-enforce-todo-dependencies is non-nil? > > Variable is nil on my side. > > - [-] Something > - [ ] one > - [ ] two > - [X] three > > I cannot mark Something to be done without marking those subordinate > items. Changing org-enforce-todo-dependencies does not change > anything. User will need to lie to oneself to close those items to > become able to close senior item. I believe it is hard-coded. One may send a feature request to have more control over this behaviour. > One would also expect that mentioned variables should influence this > type of structured action items, but it does not. It relates only to > headings. Org offers list item based actions with - [ ] but does not > handle such. > > ** TODO Buy shoes [1/3] [33%] > :PROPERTIES: > :CREATED: [2020-12-13 Sun 11:36] > :ID: d488c7e5-941a-4ce6-aec3-e1b20e1acd70 > :END: > > - [ ] Visit shop A > - [ ] Visit shop B > - [X] Visit shop C > What is good that this way the senior item can be completed without > completing subordinate items. In my opinion that is more human alike. You need org-enforce-todo-checkbox-dependencies to look into check-boxes when changing headline todo states. > If I do turn on the mentioned variable `org-enforce-todo-dependencies' > to TRUE, I can still close the senior objective here. This is good, > but variable does not do expected. > ** DONE Senior objective > CLOSED: [2020-12-13 Sun 11:22] > :PROPERTIES: > :CREATED: [2020-12-13 Sun 11:36] > :ID: 6f2fba8a-925b-4c99-9d62-5f48d433a8cc > :END: > *** TODO Subordinate action 1 > :PROPERTIES: > :CREATED: [2020-12-13 Sun 11:36] > :ID: 1c3c2da7-c564-43e0-b274-b8f0065624ec > :END: > *** TODO Subordinate action 2 > :PROPERTIES: > :CREATED: [2020-12-13 Sun 11:36] > :ID: 9cb275fd-fcbf-441c-b42d-62c82aa3ff56 > :END: >=20=20=20=20 > Variable mentions: > > Its value is t > Original value was nil > > You can customize this variable. > > Documentation: > Non-nil means undone TODO entries will block switching the parent to DONE. > Also, if a parent has an :ORDERED: property, switching an entry to DONE w= ill > be blocked if any prior sibling is not yet done. > Finally, if the parent is blocked because of ordered siblings of its own, > the child will also be blocked. > >> Non-nil means undone TODO entries will block switching the parent to DON= E. > > It obviously does not do that what me as user expects. I cannot reproduce what you observe. Also, one can forcefully change todo state to done even when org-enforce-todo-dependencies is set to TRUE. To do it, C-u C-u C-u C-c C-t needs to be used instead of C-c C-t for setting the todo state. > But I am not > asking for solution neither help in solving unsolvable issues around > Org related planning as it leads to further complexities. Those issues > are really solved on my side as I just use it for documents. Note that you are also risking to complain about things that are actually not a problem. Simply because you don't have a need to investigate what is possible. > These comments are meant for people to design their own maybe better > ways than having scattered lists everywhere. > > Jean