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

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

[Ross Patterson]

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

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

[Carsten Dominik]

Hi Ross,

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











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

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

[Ross Patterson]

Carsten Dominik <dominik@uva.nl> writes:

> Hi Ross,
>
> 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!
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

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

[Ross Patterson]

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

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

[Carsten Dominik]

On Jul 10, 2008, at 4:29 PM, Ross Patterson wrote:

> 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 believe this is *exactly* what you asked for, please
re-read your own post.  What you are asking for now seems to be pretty  
much
the original behavior...  or am I missing something?

- Carsten