From: Ihor Radchenko <yantar92@gmail.com>
To: Jean Louis <bugs@gnu.support>
Cc: daniela-spit@gmx.it, Tim Cross <theophilusx@gmail.com>,
emacs-orgmode@gnu.org
Subject: Re: Adding Org Files to org-agenda-files
Date: Tue, 01 Dec 2020 10:24:19 +0800 [thread overview]
Message-ID: <87wny2uuuk.fsf@localhost> (raw)
In-Reply-To: <X8PUxDDjQVRSybcP@protected.rcdrun.com>
Jean Louis <bugs@gnu.support> 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
next prev parent reply other threads:[~2020-12-01 2:21 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-28 15:39 Adding Org Files to org-agenda-files daniela-spit
2020-11-28 16:51 ` Jeremie Juste
2020-11-28 16:54 ` daniela-spit
2020-11-28 17:01 ` daniela-spit
2020-11-28 17:41 ` Jeremie Juste
2020-11-28 18:12 ` daniela-spit
2020-11-28 18:30 ` daniela-spit
2020-11-28 18:43 ` daniela-spit
2020-11-28 19:01 ` Jeremie Juste
2020-11-28 19:16 ` daniela-spit
2020-11-28 19:26 ` Detlef Steuer
2020-11-28 19:44 ` daniela-spit
2020-11-28 19:55 ` Jeremie Juste
2020-11-28 20:06 ` daniela-spit
2020-11-28 20:11 ` daniela-spit
2020-11-28 20:27 ` Jeremie Juste
2020-11-28 20:40 ` daniela-spit
2020-11-28 21:32 ` Jeremie Juste
2020-11-28 21:45 ` daniela-spit
2020-11-28 23:18 ` Jeremie Juste
2020-11-28 23:29 ` daniela-spit
2020-11-29 1:36 ` Tim Cross
2020-11-29 2:54 ` daniela-spit
2020-11-29 3:51 ` Tim Cross
2020-11-29 4:05 ` daniela-spit
2020-11-29 5:23 ` Tim Cross
2020-11-29 9:30 ` Jean Louis
2020-11-29 6:50 ` Jean Louis
2020-11-29 6:41 ` Jean Louis
2020-11-29 12:28 ` Ihor Radchenko
2020-11-29 13:00 ` Tim Cross
2020-11-29 17:11 ` Jean Louis
2020-11-29 17:05 ` Jean Louis
2020-12-01 2:24 ` Ihor Radchenko [this message]
2020-12-01 8:59 ` Jean Louis
2020-12-13 15:36 ` Ihor Radchenko
2020-12-13 16:27 ` steve-humphreys
2020-12-25 2:17 ` Ihor Radchenko
2020-12-13 20:21 ` Jean Louis
2020-12-13 20:59 ` Tim Cross
2020-12-13 21:59 ` pietru
2020-12-13 23:28 ` Jean Louis
2020-11-29 4:46 ` Jean Louis
2020-11-29 14:46 ` daniela-spit
2020-11-29 17:01 ` Tim Cross
2020-11-29 17:38 ` daniela-spit
2020-11-29 20:55 ` Jeremie Juste
2020-11-30 0:21 ` Tim Cross
2020-11-28 23:36 ` daniela-spit
2020-11-29 5:51 ` Jean Louis
2020-11-28 20:28 ` daniela-spit
2020-11-28 18:50 ` daniela-spit
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=87wny2uuuk.fsf@localhost \
--to=yantar92@gmail.com \
--cc=bugs@gnu.support \
--cc=daniela-spit@gmx.it \
--cc=emacs-orgmode@gnu.org \
--cc=theophilusx@gmail.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).