From mboxrd@z Thu Jan 1 00:00:00 1970 From: Max Mikhanosha Subject: Re: [PATCH] New org-depend trigger for finding next highest priority/effort item Date: Tue, 26 Jul 2011 17:56:39 -0400 Message-ID: <878vrk66zs.wl%max@openchat.com> References: <87k4b7fqu3.wl%max@openchat.com> <874o29tg8h.fsf@gnu.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Tue_Jul_26_17:56:38_2011-1" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:37348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlpcI-0008Ly-C8 for emacs-orgmode@gnu.org; Tue, 26 Jul 2011 17:56:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlpcH-00061O-9H for emacs-orgmode@gnu.org; Tue, 26 Jul 2011 17:56:42 -0400 Received: from p84-72.acedsl.com ([66.114.84.72]:59142 helo=momoland.openchat.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlpcH-00061E-1G for emacs-orgmode@gnu.org; Tue, 26 Jul 2011 17:56:41 -0400 In-Reply-To: <874o29tg8h.fsf@gnu.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: emacs-orgmode@gnu.org --Multipart_Tue_Jul_26_17:56:38_2011-1 Content-Type: text/plain; charset=US-ASCII 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? --Multipart_Tue_Jul_26_17:56:38_2011-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="org-depend-chain-find-next-test.org" Content-Transfer-Encoding: quoted-printable * Default ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO Item 4 ** NEXT Item 5 Current (mark me done) :PROPERTIES: :TRIGGER: chain-find-next(NEXT) :END: ** TODO Item 6 ** Item 7 ** TODO Item 8 ** DONE Item 9 * from-top (same as default) ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO Item 4 ** NEXT Item 5 Current (mark me done) :PROPERTIES: :TRIGGER: chain-find-next(NEXT,from-top) :END: ** TODO Item 6 ** Item 7 ** TODO Item 8 ** DONE Item 9 * from-bottom ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO Item 4 ** NEXT Item 5 Current (mark me done) :PROPERTIES: :TRIGGER: chain-find-next(NEXT,from-bottom) :END: ** TODO Item 6 ** Item 7 ** TODO Item 8 ** DONE Item 9 * from-current,priority-up ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO [#A] Item 4 ** NEXT Item 5 Current (mark me done) :PROPERTIES: :TRIGGER: chain-find-next(NEXT,from-current,priority-up) :END: ** TODO Item 6 ** Item 7 ** TODO [#B] Item 8 ** DONE Item 9 * from-current,no-wrap,priority-up ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO [#A] Item 4 ** NEXT Item 5 Current (mark me done) :PROPERTIES: :TRIGGER: chain-find-next(NEXT,from-current,no-wrap,priority-up) :END: ** TODO Item 6 ** Item 7 ** TODO [#B] Item 8 ** DONE Item 9 * from-current, without todo-only ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO Item 4 ** NEXT Item 5 Current (mark me done) :PROPERTIES: :TRIGGER: chain-find-next(NEXT,from-current) :END: ** Item 6 ** Item 7 ** TODO Item 8 ** DONE Item 9 * from-current, with todo-only ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO Item 4 ** NEXT Item 5 Current (mark me done) :PROPERTIES: :TRIGGER: chain-find-next(NEXT,from-current,todo-only) :END: ** Item 6 ** Item 7 ** TODO Item 8 ** DONE Item 9 * from-current without include-done ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO Item 4 ** NEXT Item 5 Current (mark me done) :PROPERTIES: :TRIGGER: chain-find-next(NEXT,from-current) :END: ** DONE Item 6 CLOSED: [2011-07-26 Tue 17:49] ** Item 7 ** TODO Item 8 ** DONE Item 9 * from-current with include-done ** TODO Item 1 ** TODO Item 2 ** TODO Item 3 ** TODO Item 4 ** NEXT Item 5 Current (mark me done) :PROPERTIES: :TRIGGER: chain-find-next(NEXT,from-current,include-done) :END: ** DONE Item 6 CLOSED: [2011-07-26 Tue 17:49] ** Item 7 ** TODO Item 8 ** DONE Item 9 * end --Multipart_Tue_Jul_26_17:56:38_2011-1 Content-Type: text/plain; charset=US-ASCII --Multipart_Tue_Jul_26_17:56:38_2011-1--