Re: [O] Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)

[Eric Abrahamsen]

On Sun, Sep 25 2011, Samuel Wales wrote:

> Hi Eric,
>
> Looks like you put a lot of work into this.

Not that much work, in the end -- most of the effort was figuring out
how the existing code works.

> 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.

Ha! No kidding, I guess I lost track of that in all the confusion. It
makes little difference, though: all the current setup does is put TODOs
into trees -- how you format what is wide open. To be honest I'm not
sure how one would go about "dimming" a TODO (I don't think font
properties support something like "reduce the opacity of the current
foreground color by 50%"), but that's something to look into next.

Anyway, doing it the way you want would not be hard.

Sorting is actually still an issue for you: if you ever asked for TODOs
to be sorted by effort, say, or priority, a "child" TODO could end up in
a different part of the list than an ancestor, and you'd never see that
they were related. This way, TODO subtrees always stay together.

>
>>  (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.

This is a real problem. There seem to be four or five places in the
codebase that do something like "use a regexp to search for matching
dingbats in all org files and put them in a list". More than one of
those places produces something that looks like a plain TODO list.

If the general approach here appeals, the next step would be to make it
work for todo-tags as well. I think implementing it for the daily/weekly
agenda is a bad idea (headlines and TODOs are meant to be formatted
according to time-based attributes there), and doing it for text search
would take some serious chin-scratching. But it would at least need to
be expanded into todo-tags.

What agenda commands do you use most often? Do you use multi-block
custom agenda commands?

>> +  "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.

I think we have similar goals, I just ended up with something a little
more far-reaching than what you were proposing. As I mentioned above, I
haven't implemented any dimming yet, and it would be just as easy to dim
ancestors as children (both options could be provided).

You're right, I merged the concept of dimming with skipping sublevels
(actually, with collecting TODO subtrees), because it seemed the only
way of knowing for certain what to dim was to know what belonged to what
tree. It's a little overkill just for indicating ancestors, but it works
perfectly well, and if people find it generally worthwhile it could open
the door to other tricks…

E

-- 
GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4)
 of 2011-04-04 on rothera, modified by Debian
Org-mode version 7.7 (release_7.7.320.gc8c8)