From: Carsten Dominik <dominik@uva.nl>
To: Ross Patterson <me@rpatterson.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: org-agenda-list-stuck-projects and nested projects
Date: Mon, 14 Jul 2008 12:17:47 -0700 [thread overview]
Message-ID: <54B77BB2-5855-4104-A233-B3B8CADC903A@uva.nl> (raw)
In-Reply-To: <87iqvdco7f.fsf@transitory.lefae.org>
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
prev parent reply other threads:[~2008-07-14 19:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-07 22:21 org-agenda-list-stuck-projects and nested projects Ross Patterson
2008-07-08 17:06 ` Carsten Dominik
2008-07-08 17:47 ` Ross Patterson
2008-07-10 23:29 ` Ross Patterson
2008-07-14 19:17 ` Carsten Dominik [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54B77BB2-5855-4104-A233-B3B8CADC903A@uva.nl \
--to=dominik@uva.nl \
--cc=emacs-orgmode@gnu.org \
--cc=me@rpatterson.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.