Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item

[Bastien]

Hi Max,

Max Mikhanosha <address@hidden> 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 <address@hidden>
> 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