Re: org-agenda-list-stuck-projects and nested projects

[Ross Patterson <me@rpatterson.net>]

Ross Patterson <me@rpatterson.net> writes:

> Carsten Dominik <dominik@uva.nl> 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