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 6CKiNKOoxV9NZwAA0tVLHw (envelope-from ) for ; Tue, 01 Dec 2020 02:21:23 +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 WJ1rMKOoxV9OFgAA1q6Kng (envelope-from ) for ; Tue, 01 Dec 2020 02:21:23 +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 B73D29403EC for ; Tue, 1 Dec 2020 02:21:22 +0000 (UTC) Received: from localhost ([::1]:39304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjvI8-0005bk-CP for larch@yhetil.org; Mon, 30 Nov 2020 21:21:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjvHR-0005bF-36 for emacs-orgmode@gnu.org; Mon, 30 Nov 2020 21:20:37 -0500 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]:33163) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kjvHN-0001zT-HM for emacs-orgmode@gnu.org; Mon, 30 Nov 2020 21:20:36 -0500 Received: by mail-pg1-x534.google.com with SMTP id o4so306907pgj.0 for ; Mon, 30 Nov 2020 18:20:32 -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; bh=OK/N0Q/z5uC8s1IDu1ID6Bd0sHtvtjnrAKn8dL266g4=; b=Ii6cO/gI7NqJtL18mlnRHO89TpJVoCRZ5aGmxBDICW5XD6SMCO4Y8ijXMlHbAVvYVx 94hu+w0XI+Q4yx4xsPr2B3/tJEE59vwli5DeZmyVhD/hnIUEgx0O/kjPrDa5W9uSHRqL Lpnb/rS/wrPwE35jR6rJ++syjaSKvIa/dA1i84VYx7ciNvdJr/ngqm2U9ex+NK8G7rls SbRZWhwXifMRohXgh97ADvoVaqsNJyIZTOH/Che4wQJt1CP4V43NlRzuf8m+uNFqbFiZ sYMi3R18FCfhOLsrejfI3S6kCoPyI0M9HLO7TDNSpyQugKNxuh8KiHu1yaYXrIAFDTqX RaOA== 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; bh=OK/N0Q/z5uC8s1IDu1ID6Bd0sHtvtjnrAKn8dL266g4=; b=g/TE6UV5Zm0ktG8n6/I64U3JHeGyPmQtXQVf9ZqVNS/uPrS4fa6cXkQzYwA3vNjzK4 zIaXsD7amXVwN3bpv7k4JQjiXI4yKefEj7cHjBUBjToz2w/TfbZwx03EQcJjphwhcgyq 9usO2pDUl/62JUBnIHvRn4tceaoQpM91hO9u2BSV6sj+zB3zpvqW0i6hkvSBXDcYFcO9 obMwKAlEjLKz343ZI9Hez1QLZ/TyiDT7NR5G4BNxg8NK/YAEyvFLcA9TbAJGurCJ2wAS VbCFcZuDxepyc0IWmK+FtLfiSPajJF+Ml67M9/v2cZ/QWKu6fq3jlMwLrFOBwiqq+1hM 36JQ== X-Gm-Message-State: AOAM531Wt2aX6dTuv4DykPM5p+N0NyAp+tT+wsyQq25cx/Sbcf+boQ+M sXPyTK10QtmsXbygxwoy3Gg= X-Google-Smtp-Source: ABdhPJwR984aqmD+OMkrkRgyhuX3L39kYjfsAYhOcbXcMf4xIXbSms94CnY6wO7kb/nIfjDsPoKlXw== X-Received: by 2002:aa7:9f0a:0:b029:197:e4a0:4e4d with SMTP id g10-20020aa79f0a0000b0290197e4a04e4dmr439462pfr.68.1606789231462; Mon, 30 Nov 2020 18:20:31 -0800 (PST) Received: from localhost ([103.125.234.251]) by smtp.gmail.com with ESMTPSA id o14sm386101pgh.1.2020.11.30.18.20.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Nov 2020 18:20:30 -0800 (PST) From: Ihor Radchenko To: Jean Louis Subject: Re: Adding Org Files to org-agenda-files In-Reply-To: References: <87r1od181i.fsf@gmail.com> <87h7p9135u.fsf@gmail.com> <87sg8tymeb.fsf@gmail.com> <87k0u4zupw.fsf@gmail.com> <87ft4s5oug.fsf@localhost> Date: Tue, 01 Dec 2020 10:24:19 +0800 Message-ID: <87wny2uuuk.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::534; envelope-from=yantar92@gmail.com; helo=mail-pg1-x534.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: daniela-spit@gmx.it, Tim Cross , 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: -0.69 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=gmail.com header.s=20161025 header.b=Ii6cO/gI; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: B73D29403EC X-Spam-Score: -0.69 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: 6qjTIiBaV5EG Jean Louis writes: > We write tasks in their most logical chronological order and every > staff member is instructed to follow the order. One simply cannot > drive a car without putting petrol first, so that system is > followed. Some tasks on the ground can be done without chronological > order and our staff members are left to decide on that. When they > arrive to town and need to buy timber, maybe carpenter is discovered > right there while the task says that once they arrive to village that > they should look for carpenter. What is NEXT is mostly practically > decided while doing things at my side. But what if the road to village is blocked by weather conditions? Should the staff members just stop doing the project and wait until the road becomes accessible? That sounds not very efficient. If all the tasks that one can start doing at current stage of the project are marked NEXT, instead of waiting for the blocked tasks, one can simply choose another NEXT task and get some progress on the project despite the first tasks cannot be done at this moment. > Interesting complication (Edna) that is supposed to be useful. Before > constructing the series of those tasks user would need to construct > series of tasks to construct series of tasks. > > Concept is great: This task can be completed only when tasks 1, 4 and > 7 are completed. But practical life is different. When conducting > projects staff members may discover on ground that dependable task can > be completed without 1, 4 and 7 being completed as one could not > predict future randomity. It may be also discovered that those 1, 4 > and 7 are not true dependencies but some other tasks. This would imply > that planner must know very well future incidents which is rarely the > case as it would be so easy to predict future one would not be writing > tasks. This can indeed be problem, especially if one tries to create too detailed dependencies. However, some very standard procedures might still benefit from this. For example, safety checklists might be the case when such task dependencies do make sense. Both the checklist and the dependency can be pre-defined as a capture template and then used in different projects serving as a reminder for necessary actions. I personally use very simple edna dependencies - when there is a book series or a movie/documentary split into several series, I sometimes block the later series until I watch earlier: https://github.com/yantar92/emacs-config/blob/master/config.org#task-dependencies In any case, I suggested this package simply as an example how to make all subheadings become TODO as soon as one changes the parent to TODO state. > It is useful in trees and it should be an org built-in to mark all > children nodes with the tag. It becomes very trivial when using > database with nodes having a parent: > > ,---- > | UPDATE hlinks SET hlinks_tags = 'TODO' WHERE hlinks_parent = THIS ONE; > `---- > > But rather a function would be used or type assigned. The above is > only example that shows how complex hard coded Elisp functions can be > replaced with 3-4 lines single function when database is a backend. Why do you think that analogous Elisp function would be complex? (defun yant/trigger-children (arg) "Change all the children to TODO when parent is TODO." (when (and (eq (plist-get arg :type) 'todo-state-change) (not (boundp 'trigger-children-progress)) (string= (plist-get arg :to) "TODO")) (let (trigger-children-progress) (org-map-tree (lambda () (org-todo "TODO")))))) (add-hook 'org-trigger-hook #'yant/trigger-children) > No wonder this guy has put Org mode in a sandwich on the logo of > SMOS. It eats the Org. > > SMOS - A Comprehensive Self-Management System > https://smos.cs-syd.eu/features As for me, SMOS is too inflexible in comparison with org-mode. See https://old.reddit.com/r/orgmode/comments/ivlczu/smos_a_comprehensive_selfmanagement_tool/ Best, Ihor