Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item
Hi Max, Max Mikhanosha writes: > At Wed, 27 Jul 2011 13:33:16 +0200, > Bastien wrote: >> >> Also, it would be really nice to update this tutorial on Worg and to >> show how to use the new feature you introduced: >> >> http://orgmode.org/worg/org-contrib/org-depend.html > > Done, will push once I have permissions Great -- thanks. The person to contact to get write access to Worg's repo is Matt Lundin, but if you give me your username on repo.or.cz I can add you now. Best, -- Bastien
Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item
At Wed, 27 Jul 2011 13:33:16 +0200, Bastien wrote: > > Also, it would be really nice to update this tutorial on Worg and to > show how to use the new feature you introduced: > > http://orgmode.org/worg/org-contrib/org-depend.html > Done, will push once I have permissions
Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item
Hi Max, Max Mikhanosha writes: > Amended patch attached, changes: > > - use (eval-when-compile) with require 'cl > - changed include-done to todo-and-done-only > - Added defcustom org-depend-find-next-options for default options > which are now: from-current,todo-only,priority-up > - cleaned up documentation Great. Applied, thanks for the fast rewrite! -- Bastien
Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item
Hi Max, Max Mikhanosha writes: >> Can you give an example? > > * Parent > ** TODO Item 1 > ** TODO Item 2 > ** TODO Item 3 > ** TODO Item 4 > ** NEXT Item 5 Current (the one with TRIGGER property) > ** TODO Item 6 > ** Item 7 > ** TODO Item 8 > ** DONE Item 9 > > Below are example list of candidates depending on option > > from-top => 1,2,3,4,6,7,8 > from-bottom => 8,7,6,4,3,2,1 > from-current => 6,7,8,1,2,3,4 > from-current,no-wrap => 6,7,8 > > Adding todo-only will eliminate item 7 from all of above, adding > include-done will include item 9. > > After inital candidate list is established as above, its sorted by priority > or effort, then 1st item is made NEXT. Cristal-clear, thanks! > I grepped *.el and saw other file using it without eval-when-compile > (it was htmlize.el i think), so I thought it was ok in contrib. To be clear: it *is* okay in contrib/ as files in contrib/ will not go to Emacs core. But the more we can avoid this the better. > Attached is a test file you can use for all the situation that you > asked clarification for. After testing this file I'm thinking maybe > from-current should be a default instead of from-top. Yes, I also think from-current should be the default. Also, it would be really nice to update this tutorial on Worg and to show how to use the new feature you introduced: http://orgmode.org/worg/org-contrib/org-depend.html Thanks! -- Bastien
Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item
Amended patch attached, changes: - use (eval-when-compile) with require 'cl - changed include-done to todo-and-done-only - Added defcustom org-depend-find-next-options for default options which are now: from-current,todo-only,priority-up - cleaned up documentation Also attached is updated test file, added #+TODO line since NEXT is not in default list of keywords. Content-Disposition: attachment; filename="0011-Add-chain-find-next-trigger-option.patch"][8bit]] From 6140261b2fe0e15ac36d8222c38790680cd3f9d4 Mon Sep 17 00:00:00 2001 From: Max Mikhanosha Date: Sun, 24 Jul 2011 14:44:44 -0400 Subject: [PATCH 11/11] Add chain-find-next trigger option. --- contrib/lisp/org-depend.el | 145 +++- 1 files changed, 143 insertions(+), 2 deletions(-) diff --git a/contrib/lisp/org-depend.el b/contrib/lisp/org-depend.el index 089a6a0..77a7c68 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-find-next", so the chain can continue. +;; +;;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 +;; +;;- todo-only Only consider siblings that have a todo keyword +;;- +;;- todo-and-done-only +;;Same as above but also include done items. +;; +;;- 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,12 +157,20 @@ ;; (require 'org) +(eval-when-compile + (require 'cl)) (defcustom org-depend-tag-blocked t "Whether to indicate blocked TODO items by a special tag." :group 'org :type 'boolean) +(defcustom org-depend-find-next-options + "from-current,todo-only,priority-up" + "Default options for chain-find-next trigger" + :group 'org + :type 'string) + (defmacro org-depend-act-on-sibling (trigger-val &rest rest) "Perform a set of actions on the next sibling, if it exists, copying the sibling spec TRIGGER-VAL to the next sibling." @@ -143,6 +187,8 @@ copying the sibling spec TRIGGER-VAL to the next sibling." (org-entry-add-to-multivalued-property nil "TRIGGER" ,trigger-val +(defvar org-depend-doing-chain-find-next nil) + (defun org-depend-trigger-todo (change-plist) "Trigger new TODO entries after the current is switched to DONE. This does two different kinds of triggers: @@ -184,12 +230,107 @@ This does two different kinds of triggers: ;; Go through all the triggers (while (setq tr (pop triggers)) (cond +((and (not org-depend-doing-chain-find-next) + (string-match "\\`chain-find-next(\\b\\(.+?\\)\\b\\(.*\\))\\'" tr)) + ;; smarter sibling selection + (let* ((org-depend-doing-chain-find-next t) +(kwd (match-string 1 tr)) +(options (match-string 2 tr)) +(options (if (or (null options) + (equal options "")) + org-depend-find-next-options + options)) +(todo-only (string-match "todo-only" options)) +(todo-and-done-only (string-match "todo-and-done-only" + options)) +(from-top (string-match "from-top" options)) +(from-bottom (string-match "from-bottom" options)) +(from-current (string-match "from-current" options)) +(no-wrap (string-match "no-
Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item
At Tue, 26 Jul 2011 13:48:30 +0200, Bastien wrote: > > > +;; 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? Yes thats a typo, I was trying to select a more appropriate name for it. > > +;;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? * Parent ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO Item 4 ** NEXT Item 5 Current (the one with TRIGGER property) ** TODO Item 6 ** Item 7 ** TODO Item 8 ** DONE Item 9 Below are example list of candidates depending on option from-top => 1,2,3,4,6,7,8 from-bottom => 8,7,6,4,3,2,1 from-current => 6,7,8,1,2,3,4 from-current,no-wrap => 6,7,8 Adding todo-only will eliminate item 7 from all of above, adding include-done will include item 9. After inital candidate list is established as above, its sorted by priority or effort, then 1st item is made NEXT. > > +;; > > +;;- 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. Agree, maybe whole option can be eliminated, I had an opposite option initially (skip-done), to have default compatible with original trigger, but decided that skipping done may be a better default. > > +;;- 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? todo-only excludes items without any todo keyword, ie plain headlines. See example above on if item 7 is included or not. include-done forces items with a DONE/CANCELLEd keyword to be considered > > What about using exclusive options like "todo-only" and > "todo-and-done-only"? So that you would need to use only one. I'm fine with that, will change. > > > > (require 'org) > > +(require 'cl) > > this (eval-when-compile (require 'cl)) -- emacs has a policy of > preventing (require 'cl) only... I grepped *.el and saw other file using it without eval-when-compile (it was htmlize.el i think), so I thought it was ok in contrib. My worry was that using functions as opposite to macros needs it loaded, since I use (remove-if) and (position) But I just tested it on clean file and emacs -Q, and (eval-when-compile (require 'cl)) and then using 'cl-seq functions like remove-if seems to works fine. I'll submit updated patch later today taken above comments inte consideration. Attached is an org file where you can test various options > 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. Attached is a test file you can use for all the situation that you asked clarification for. After testing this file I'm thinking maybe from-current should be a default instead of from-top. Basically I'm open to suggestion as to the most sensible default options. I myself use a hook that auto-inserts TRIGGER line i want when entry becomes next, maybe such hook should be included into org-depend also? At least as example? org-depend-chain-find-next-test.org Description: Binary data
Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item
"Sebastien Vauban" writes: > Shouldn't we do that (require cl only) in our custom .emacs files > neither? ~/.emacs.el is precisely the place where you do what you want :) -- Bastien
Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item
Hi Bastien, Bastien wrote: >> +(require 'cl) > > This (eval-when-compile (require 'cl)) -- Emacs has a policy of > preventing (require 'cl) only... Shouldn't we do that (require cl only) in our custom .emacs files neither? I do have such for accessing functions like `push'... Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] New org-depend trigger for finding next highest priority/effort item
Hi Max, Max Mikhanosha 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 > 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
[O] [PATCH] New org-depend trigger for finding next highest priority/effort item
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. Example: chain-find-next(NEXT,from-current,priority-up,todo-only) 0011-Add-chain-find-next-trigger-option.patch Description: Binary data
