From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Patterson Subject: Re: org-agenda-list-stuck-projects and nested projects Date: Thu, 10 Jul 2008 16:29:56 -0700 Message-ID: <87iqvdco7f.fsf@transitory.lefae.org> References: <87wsjxnxnn.fsf@transitory.lefae.org> <2000F983-CA16-4A50-9AE5-9BE3CF830746@uva.nl> <87fxqknu8i.fsf@transitory.lefae.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KH5aZ-000575-9S for emacs-orgmode@gnu.org; Thu, 10 Jul 2008 19:30:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KH5aX-00055l-Rk for emacs-orgmode@gnu.org; Thu, 10 Jul 2008 19:30:14 -0400 Received: from [199.232.76.173] (port=58873 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KH5aX-00055T-B0 for emacs-orgmode@gnu.org; Thu, 10 Jul 2008 19:30:13 -0400 Received: from main.gmane.org ([80.91.229.2]:38323 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KH5aV-00055Z-Ty for emacs-orgmode@gnu.org; Thu, 10 Jul 2008 19:30:13 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KH5aT-0006gD-5R for emacs-orgmode@gnu.org; Thu, 10 Jul 2008 23:30:09 +0000 Received: from dsl-63-249-88-109.cruzio.com ([63.249.88.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Jul 2008 23:30:09 +0000 Received: from me by dsl-63-249-88-109.cruzio.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Jul 2008 23:30:09 +0000 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Ross Patterson writes: > Carsten Dominik writes: > >> The "stuck projects" view depends on the hypothesis that you can >> clearly identify what a "project means". In the default setup, projects >> are assumed to have LEVEL=2 and should not be DONE. >> >> In the hierarchy you are using, it seems that any entry can be called a >> "projects", and that you do have projects within projects. So the >> idea that >> you need to avoid skipping subtrees and limit yourself to skipping >> entries only >> is the right approach. >> >> However, what you are really asking for is to look only at direct >> children, >> and in this case is is better to write a special skip function: >> >> (defun org-skip-unless-child-todo () >> (let ((subtree-end (save-excursion (org-end-of-subtree t))) >> (entry-end (save-excursion (or (outline-next-heading) (point-max))))) >> (if (re-search-forward >> (concat "^" (regexp-quote >> (make-string (1+ level) ?*)) >> "[ \t]+" >> "\\(" >> (mapconcat 'identity org-not-done-keywords "\\|") >> "\\)") >> subtree-end t) >> ;; skip this entry by returning the entry-end position >> entry-end >> ;; do not skip this entry by returning nil >> nil))) >> >> As you can see, this function first determines the end of the subtree >> (for the search) and the end of the entry positions. Then it creates >> a special regular expression that will only match headlines that are >> direct children of the current level. During a tags search, the >> "level" variable contains the current level (careful, when you are >> using org-odd-levels-only, it contains the reduced level...). >> So the special regexp contains one star more that the current, and then >> any TODO keyword. >> >> If there is a TODO child, the function returns the position at the end >> of >> entry, to continue search from there. >> >> If there is no mach, it returns nil, meaning that this entry should >> *not* be skipped. >> >> The agenda custom command would look like this: >> >> (("0" "Special Stuck" tags "LEVEL>0/-DONE-TODO" >> ((org-agenda-skip-function 'org-skip-unless-child-todo))) >> >> So we select entries that are LEVEL>0, i.e. all entries, but we require >> that these entries are not TODO entries. OK, these are the candidate >> projects. And the we skip them when they have a direct TODO child. >> >> HTH >> >> - Carsten > > Wow, that is a response and a half! Looks like you've pretty much done > it for me. Thanks so much! I'll let you know how it works. Thanks again for that function and custom command. They work like a charm! Having gotten to use them for a bit, I wonder if one refinement would be possible. Consider the following tree: * Testing ** Project *** Sub-project **** TODO Task With the custom command you provided, the "* Project" entry will be reported as a stuck project. Ideally, I'd like it not to be considered a stuck project. I'm not familiar with how the agenda "skipping" works so I don't know if this is possible, but I'd like a heading to be skipped if all it's immediate children are either active TODO's or are skipped themselves. It's a recursive definition. Is that possible? Ross >> On Jul 7, 2008, at 3:21 PM, Ross Patterson wrote: >> >>> One of the things I love about org-mode is that it's generally >>> hierarchy >>> agnostic which is to say it doesn't care what level or depth entries >>> are >>> with regards to the functionality org-mode provides with entries >>> (TODOs, >>> Dates and times, tags, etc.). >>> >>> Many of the projects I'd like to manage with org-mode are fairly large >>> and as such I'd like to make use of org-mode's heirarchical >>> agnosticism >>> to factor my projects into nested projects arbitrary depth. This is >>> supported very well by the rest of org-mode, just not the stuck >>> projects >>> agenda view. >>> >>> I find that view very valuable, but if I have a project with lots of >>> branches that can move in parallel and one of those branches is stuck >>> but another isn't stuck, then the stuck projects report doesn't >>> reflect >>> this assuming that if one branch isn't stuck then the project isn't >>> stuck. Since the project is very large, that means I have to inspect >>> the whole tree to figure out what might be stuck. The only workaround >>> with the current implementation is that anytime I have a >>> project/sub-project/branch lower than LEVEL=2 that I need to be able >>> to >>> review, then I have to break it out to a LEVEL=2 headline. This >>> creates >>> a negative feedback which will probably result in me not using the >>> stuck >>> projects view and probably insufficiently reviewing my projects. >>> >>> What I'd like is an agenda view like the stuck projects view but >>> rather >>> than omitting any project that has any active TODO's all the way up >>> the >>> hierarchy, it will only omit headlines that have active TODO's among >>> its >>> immediate children. >>> >>> If I start with a test.org file like so: >>> >>> * Testing >>> ** Stuck Project at Level 2 >>> *** Sub-project at Level 3 >>> **** DONE bar >>> *** Sub-project 2 at Level 3 >>> >>> And customize org-stuck-projects to remove the LEVEL=2 restriction >>> like >>> so: >>> >>> (setq org-stuck-projects '("/-DONE" ("TODO") nil "")) >>> >>> And finally customize the org-tags-match-list-sublevels to allow tags >>> matching to descend. >>> >>> Then if I open test.org and do "C-c a < #" I get: >>> >>> List of stuck projects: >>> test: .Stuck Project at Level 2 >>> test: ..Sub-project at Level 3 >>> test: ..Sub-project 2 at Level 3 >>> >>> Then if I re-activate the bar heading by putting it in the TODO state: >>> >>> * Testing >>> ** Stuck Project at Level 2 >>> *** Sub-project at Level 3 >>> **** TODO bar >>> *** Sub-project 2 at Level 3 >>> >>> I get an empty list: >>> >>> List of stuck projects: >>> >>> I'd like a list with the sub-heading that is still stuck: >>> >>> List of stuck projects: >>> test: .Stuck Project at Level 2 >>> test: ..Sub-project 2 at Level 3 >>> >>> I tried modifying the org-agenda-list-stuck-projects function by >>> implementing an org-agenda-skip-function that only skips the heading >>> and not the whole subtree: >>> >>> (defun org-agenda-skip-entry-when-regexp-matches () >>> "Checks if the current entry contains match for `org-agenda- >>> skip-regexp'. >>> If yes, it returns the end position of this entry, causing agenda >>> commands to skip this entry. This is a function that can be put >>> into `org-agenda-skip-function' for the duration of a command." >>> (org-agenda-skip-if nil '(regexp org-agenda-skip-regexp))) >>> >>> Then I replaced the org-agenda-skip-function set in >>> org-agenda-list-stuck-projects by replacing: >>> >>> (let* ((org-agenda-skip-function 'org-agenda-skip-subtree-when- >>> regexp-matches) >>> >>> with: >>> >>> (let* ((org-agenda-skip-function >>> org-agenda-skip-entry-when-regexp- >>> matches) >>> >>> But that gets me: >>> >>> List of stuck projects: >>> test: .Stuck Project at Level 2 >>> test: ..Sub-project at Level 3 >>> test: ...TODO bar >>> test: ..Sub-project 2 at Level 3 >>> >>> I'm new to the internals of org-mode. Can anyone help me figure out >>> what's wrong with my attempted solution here? >>> >>> Ross > > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode