emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Dimming ancestors in the agenda (relevant to indenting nested TO


From: Samuel Wales
Subject: Re: [O] Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
Date: Sat, 24 Sep 2011 16:54:29 -0700

Hi Eric,

Looks like you put a lot of work into this.

Some comments:

On 2011-09-24, Eric Abrahamsen <address@hidden> wrote:
> along the way. One bonus is that each level of TODO
> subtrees gets sorted distinctly.

My goal (which might be different from yours) is as stated
in the subject header; it's merely to dim any agenda entry
that has any descendent of it anywhere in the same agenda.

There would be no other differences, so sorting would be the
same.

>  (defcustom org-agenda-todo-list-sublevels t
> - "Non-nil means check also the sublevels of a TODO entry
> for TODO entries.

This looks like it only works for the agenda command(s) that
list(s) todos, not for tags, text search, or daily/weekly
agenda.  Is that correct?

I reviewed the manual and
http://orgmode.org/worg/org-tutorials/advanced-searching.html#combining-metadata-and-full-text-queries
.

I've actually never understood the usefulness of the c-c a t
view, given that all todo searches (IIUC) can in principle
be implemented with a tags search and c-c a t would take
forever with a large set of agenda files.  Also, I rarely
use T (and only interactively) and never use M.

So your patch would actually not be useful to me, as I
essentially don't use the todo searches.

> +  "How to display TODO entries that are sublevels of a TODO entry.
> +When nil, the sublevels of a TODO entry are not returned,
> +resulting in potentially much shorter TODO lists. When t, the

This seems to allow you to dim sublevels, not ancestors.  So
it is actually the opposite of this thread's subject.

Also, it seems to merge the concept of skipping sublevels
with dimming.  My guess is that they should be separated.
Of course, it is your code and you know it best.

Dimming of ancestors can be done after the entire agenda is
created.  So it need not be involved in the initial scanning
of the outline at all, unless that is needed for efficiency.

===

It is probable that I do not understand what your goal is,
as it is different from mine.  The two goals might or might
not be advisable to implement with the same approach.

My goal is simply to dim anything in the agenda that has any
descendant that is also showing in the agenda, efficiently.

That way, if you have a project and a NEXT underneath it,
the project will be dimmed and the NEXT will not, without
any manual manipulation of metadata necessary.

Hope it helps.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
I support the Whittemore-Peterson Institute (WPI)
===
Bigotry against people with serious diseases is still bigotry.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]