Hi Max,
Max Mikhanosha <m...@openchat.com> writes:
> org-depend TRIGGER chain-siblings(NEXT) property is hardly usable for
> me, because it requires too much effort to keep items nicely sorted.
>
> For example if next headline is already in DONE state, chain-siblings
> would still change it. I prefer to sort my items by setting their
> priorities and/or effort estimate, leaving DONE items in place for
> some time.
>
> Attached patch implements new TRIGGER chain-find-next(NEXT[,options])
> trigger, which allows to flexibly select which of the siblings will be
> changed to NEXT.
Thanks for this!
> Example: chain-find-next(NEXT,from-current,priority-up,todo-only)
>
>
>>From 10ac42d25793eedc595641555186321219818cec Mon Sep 17 00:00:00 2001
> From: Max Mikhanosha <m...@openchat.com>
> Date: Sun, 24 Jul 2011 14:44:44 -0400
> Subject: [PATCH 11/11] Add chain-find-next trigger option.
>
> ---
> contrib/lisp/org-depend.el | 142
> +++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 140 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/lisp/org-depend.el b/contrib/lisp/org-depend.el
> index 089a6a0..aa8e728 100644
> --- a/contrib/lisp/org-depend.el
> +++ b/contrib/lisp/org-depend.el
> @@ -55,7 +55,43 @@
> ;; - The sibling also gets the same TRIGGER property
> ;; "chain-siblings-scheduled", so the chain can continue.
> ;;
> -;; 3) If the TRIGGER property contains any other words like
> +;; 3) If the TRIGGER property contains the string
> +;; "chain-find-next(KEYWORD[,OPTIONS])", then switching that entry
> +;; to DONE do the following:
> +;; - All siblings are of the entry are collected into a temporary
> +;; list and then filtered and sorted according to OPTIONS
> +;; - The first sibling on the list is changed into KEYWORD state
> +;; - The sibling also gets the same TRIGGER property
> +;; "chain-siblings-scheduled", so the chain can continue.
^^^^^^^^^^^^^^^^^^^^^^^^
This should rather be "chain-find-next" here, right?
> +;; OPTIONS should be a comma separated string without spaces, and
> +;; can contain following options:
> +;;
> +;; - from-top the candidate list is all of the siblings in
> +;; the current subtree
> +;;
> +;; - from-bottom candidate list are all siblings from bottom up
> +;;
> +;; - from-current candidate list are all siblings from current item
> +;; until end of subtree, then wrapped around from
> +;; first sibling
> +;;
> +;; - no-wrap candidate list are siblings from current one down
I'm not sure to understand the difference between "from-top" and
"from-current", and between "from-top" and "no-wrap".
Can you give an example?
> +;;
> +;; - include-done include siblings with TODO in `org-done-keywords',
> +;; they are excluded by default
The phrasing is a bit confusing to me -- perhaps removing "they are
excluded by default" is enough.
> +;; - todo-only Only consider siblings that have TODO only, by default
> +;; siblings without TODO keyword are considered too
I suggest this:
"Only consider siblings that have a TODO keyword."
I suppose "todo-only" and "include-done" are compatible, right?
What about using exclusive options like "todo-only" and
"todo-and-done-only"? So that you would need to use only one.
> +;; - priority-up sort by highest priority
> +;; - priority-down sort by lowest priority
> +;; - effort-up sort by highest effort
> +;; - effort-down sort by lowest effort
> +;;
> +;; Default OPTIONS are from-top
> +;;
> +;;
> +;; 4) If the TRIGGER property contains any other words like
> ;; XYZ(KEYWORD), these are treated as entry id's with keywords. That
> ;; means Org-mode will search for an entry with the ID property XYZ
> ;; and switch that entry to KEYWORD as well.
> @@ -121,6 +157,7 @@
> ;;
>
> (require 'org)
> +(require 'cl)
This (eval-when-compile (require 'cl)) -- Emacs has a policy of
preventing (require 'cl) only...
Thanks for further feedback on this! If you can provide a small
Org file where I can test the new functionalities that will help
a lot.
Best,
--
Bastien
