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

[Bastien]

Hi Eric,

Eric Abrahamsen e...@ericabrahamsen.net writes:

 if I revisited nested todos, I would just write it on top of
 org-element, rather than the existing org-agenda code. Eventually!

Great.  Let's keep the future open then :)

-- 
 Bastien

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

[Eric Abrahamsen]

On Tue, Apr 24 2012, Bastien wrote:

 Hi Eric,

 Eric Abrahamsen e...@ericabrahamsen.net writes:

 Okay, here's an attempt at indicating nested todos in the todo agenda
 view.

 Sorry to come back to this old patch -- I tried it (I had to rework it
 to apply it against current git master) and it doesn't work, some calls 
 go beyond `max-lisp-eval-depth' (I don't have a backtrace right now.)

 I marked the patch as Not applicable on the patchwork.

 If you are still interested in progress in this area and have something 
 to test, please let us know. 

 Thanks!

Hi Bastien,

No worries, that was an old patch and I'm not surprised it doesn't apply
cleanly anymore. More importantly, I think what I was trying to do is
being superseded by org-element. The goal was to have a way to indicate
nested todos in the agenda view, and this particular patch made that
happen by collecting todos into a tree, not a flat list. org-element
does the same thing (and much more) for different purposes; if I
revisited nested todos, I would just write it on top of org-element,
rather than the existing org-agenda code. Eventually!

Thanks,
Eric

-- 
GNU Emacs 24.1.50.2 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
 of 2012-04-15 on pellet

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

[Bastien]

Hi Eric,

Eric Abrahamsen e...@ericabrahamsen.net writes:

 Okay, here's an attempt at indicating nested todos in the todo agenda
 view.

Sorry to come back to this old patch -- I tried it (I had to rework it
to apply it against current git master) and it doesn't work, some calls 
go beyond `max-lisp-eval-depth' (I don't have a backtrace right now.)

I marked the patch as Not applicable on the patchwork.

If you are still interested in progress in this area and have something 
to test, please let us know. 

Thanks!

-- 
 Bastien

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

[Eric Abrahamsen]

Okay, here's an attempt at indicating nested todos in the todo agenda
view.

The more I futzed with comparing consecutive TODOs the hackier it
seemed, so I went with something more fundamental. Right now I think
this is a bigger solution than the problem warranted, but it might also
open the way to other interesting features, so I'm floating it here.

With the attached patch, and the variable
`org-agenda-todo-list-sublevels' set to anything but nil,
`org-agenda-get-todos' will put todos into nested lists, rather than a
flat list.

While that's happening, TODOs can be formatted differently to indicate
their depth within TODO subtrees. Currently that's hardcoded to the
venerable leading dots, but symbol values for
`org-agenda-todo-list-sublevels' could provide for a wider variety of
formatting options, or a custom function.

Then `org-finalize-agenda-entries' unwinds the nested lists back into a
flat list (using a flatten pattern straight out of Paul Graham),
applying the necessary filtering, highlighting and sorting functions
along the way. One bonus is that each level of TODO subtrees gets sorted
distinctly.

Two questions:

1. Is this buggy or broken or unnecessarily slow?
2. Is this justified? Can we do other cool stuff with this?

That's all. Hope it works!

Eric

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index b1fa5f5..417566d 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -587,12 +587,19 @@ When nil, these trees are also scanned by agenda 
commands.
   :type 'boolean)
 
 (defcustom org-agenda-todo-list-sublevels t
-  Non-nil means check also the sublevels of a TODO entry for TODO entries.
-When nil, the sublevels of a TODO entry are not checked, resulting in
-potentially much shorter TODO lists.
+  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
+default, show all TODO entries as a flat list. 'indent and 'fade
+change the way TODO entries that follow a parent TODO are
+displayed.
   :group 'org-agenda-skip
   :group 'org-agenda-todo-list
-  :type 'boolean)
+  :type '(choice
+ (const :tag Create a flat list of sublevels t)
+ (const :tag Do not list sublevel todos nil)
+ (const :tag Indent sublevel todos indent)
+ (const :tag Fade out sublevel todos fade)))
 
 (defcustom org-agenda-todo-ignore-with-date nil
   Non-nil means don't show entries with a date in the global todo list.
@@ -4582,40 +4590,57 @@ the documentation of `org-diary'.
   (mapconcat 'identity
  (org-split-string
   org-select-this-todo-keyword 
|) \\|)
-\\)\\))
+  \\)\\))
   org-not-done-regexp)
 [^\n\r]*\\)))
-marker priority category category-pos tags todo-state ee txt beg end)
-(goto-char (point-min))
-(while (re-search-forward regexp nil t)
-  (catch :skip
-   (save-match-data
- (beginning-of-line)
- (org-agenda-skip)
- (setq beg (point) end (save-excursion (outline-next-heading) (point)))
- (when (org-agenda-check-for-timestamp-as-reason-to-ignore-todo-item 
end)
-   (goto-char (1+ beg))
-   (or org-agenda-todo-list-sublevels (org-end-of-subtree 'invisible))
-   (throw :skip nil)))
-   (goto-char (match-beginning 1))
-   (setq marker (org-agenda-new-marker (match-beginning 0))
- category (org-get-category)
- category-pos (get-text-property (point) 'org-category-position)
- txt (match-string 1)
- tags (org-get-tags-at (point))
- txt (org-format-agenda-item  txt category tags)
- priority (1+ (org-get-priority txt))
- todo-state (org-get-todo-state))
-   (org-add-props txt props
- 'org-marker marker 'org-hd-marker marker
- 'priority priority 'org-category category
- 'org-category-position category-pos
- 'type todo 'todo-state todo-state)
-   (push txt ee)
-   (if org-agenda-todo-list-sublevels
-   (goto-char (match-end 1))
- (org-end-of-subtree 'invisible
-(nreverse ee)))
+(depth 0))
+
+(flet ((mk-td (start finish)
+ (goto-char start)
+ (let (marker priority category category-pos tags todo-state 
ee txt beg end)
+   (while (re-search-forward regexp finish t)
+ (catch :skip
+   (save-match-data
+ (beginning-of-line)
+ (org-agenda-skip)
+ (setq beg (point) end (save-excursion 
(outline-next-heading) (point)))
+ (when 

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

[Eric Abrahamsen]

On Sat, Sep 24 2011, Eric Abrahamsen wrote:

 Okay, here's an attempt at indicating nested todos in the todo agenda
 view.

That might not have been the most useful way to attach the diff, sorry.

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index b1fa5f5..417566d 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -587,12 +587,19 @@ When nil, these trees are also scanned by agenda commands.
   :type 'boolean)
 
 (defcustom org-agenda-todo-list-sublevels t
-  Non-nil means check also the sublevels of a TODO entry for TODO entries.
-When nil, the sublevels of a TODO entry are not checked, resulting in
-potentially much shorter TODO lists.
+  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
+default, show all TODO entries as a flat list. 'indent and 'fade
+change the way TODO entries that follow a parent TODO are
+displayed.
   :group 'org-agenda-skip
   :group 'org-agenda-todo-list
-  :type 'boolean)
+  :type '(choice
+	  (const :tag Create a flat list of sublevels t)
+	  (const :tag Do not list sublevel todos nil)
+	  (const :tag Indent sublevel todos indent)
+	  (const :tag Fade out sublevel todos fade)))
 
 (defcustom org-agenda-todo-ignore-with-date nil
   Non-nil means don't show entries with a date in the global todo list.
@@ -4563,6 +4570,7 @@ the documentation of `org-diary'.
 		  (setq results (append results rtn
 	results
 
+
 (defun org-agenda-get-todos ()
   Return the TODO information for agenda display.
   (let* ((props (list 'face nil
@@ -4582,40 +4590,57 @@ the documentation of `org-diary'.
    (mapconcat 'identity
 		  (org-split-string
 		   org-select-this-todo-keyword |) \\|)
- \\)\\))
+   \\)\\))
 			   org-not-done-regexp)
 			 [^\n\r]*\\)))
-	 marker priority category category-pos tags todo-state ee txt beg end)
-(goto-char (point-min))
-(while (re-search-forward regexp nil t)
-  (catch :skip
-	(save-match-data
-	  (beginning-of-line)
-	  (org-agenda-skip)
-	  (setq beg (point) end (save-excursion (outline-next-heading) (point)))
-	  (when (org-agenda-check-for-timestamp-as-reason-to-ignore-todo-item end)
-	(goto-char (1+ beg))
-	(or org-agenda-todo-list-sublevels (org-end-of-subtree 'invisible))
-	(throw :skip nil)))
-	(goto-char (match-beginning 1))
-	(setq marker (org-agenda-new-marker (match-beginning 0))
-	  category (org-get-category)
-	  category-pos (get-text-property (point) 'org-category-position)
-	  txt (match-string 1)
-	  tags (org-get-tags-at (point))
-	  txt (org-format-agenda-item  txt category tags)
-	  priority (1+ (org-get-priority txt))
-	  todo-state (org-get-todo-state))
-	(org-add-props txt props
-	  'org-marker marker 'org-hd-marker marker
-	  'priority priority 'org-category category
-	  'org-category-position category-pos
-	  'type todo 'todo-state todo-state)
-	(push txt ee)
-	(if org-agenda-todo-list-sublevels
-	(goto-char (match-end 1))
-	  (org-end-of-subtree 'invisible
-(nreverse ee)))
+	 (depth 0))
+
+(flet ((mk-td (start finish)
+		  (goto-char start)
+		  (let (marker priority category category-pos tags todo-state ee txt beg end)
+		(while (re-search-forward regexp finish t)
+		  (catch :skip
+			(save-match-data
+			  (beginning-of-line)
+			  (org-agenda-skip)
+			  (setq beg (point) end (save-excursion (outline-next-heading) (point)))
+			  (when (org-agenda-check-for-timestamp-as-reason-to-ignore-todo-item end)
+			(goto-char (1+ beg))
+			(or org-agenda-todo-list-sublevels (org-end-of-subtree 'invisible))
+			(throw :skip nil)))
+			(goto-char (match-beginning 1))
+			(setq marker (org-agenda-new-marker (match-beginning 0))
+			  category (org-get-category)
+			  category-pos (get-text-property (point) 'org-category-position)
+			  txt (concat (if
+	  ( depth 0)
+	  (make-string (* 2 depth) ?.)
+	) (match-string 1))
+			  tags (org-get-tags-at (point))
+			  txt (org-format-agenda-item  txt category tags depth)
+			  priority (1+ (org-get-priority txt))
+			  todo-state (org-get-todo-state))
+			(org-add-props txt props
+			  'org-marker marker 'org-hd-marker marker
+			  'priority priority 'org-category category
+			  'org-category-position category-pos
+			  'type todo 'todo-state todo-state)
+			(if (not org-agenda-todo-list-sublevels)
+			(progn
+			  (push txt ee)
+			  (org-end-of-subtree 'invisible))
+			  (goto-char (match-end 0))
+			  (let* ((depth (1+ depth))
+ (subtree-todos
+  (mk-td (point)
+	 (save-excursion (org-end-of-subtree 'invisible) (point)
+			(when subtree-todos
+			  (setq txt (cons txt (nreverse subtree-todos
+			(push txt ee)
+		ee)))
+  (goto-char (point-min))
+  (nreverse (mk-td (point) (point-max))
+
 
 (defun 

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

[Samuel Wales]

Hi Eric,

Looks like you put a lot of work into this.

Some comments:

On 2011-09-24, Eric Abrahamsen e...@ericabrahamsen.net 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.

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 e...@ericabrahamsen.net 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)

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

[Samuel Wales]

On 2011-09-24, Eric Abrahamsen e...@ericabrahamsen.net wrote:
 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.

Just a face.  Simple.

 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.

Nope, moving entries from their current sort order into an order that
addresses hierarchy is not a requirement at this time (for me).
Sorting does not need to change.

My goal is simple: go through entries in the already-built agenda and
dim anything that has a descendent in the same agenda.

Hierarchical sorting is for the future.  And it is undesirable if you
do not have the horizontal real estate to indent.

Note: I say entry meaning a headline in the agenda; todo entries are
only a subset of those and I don't want to limit to todo entries.

 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.

IMO ideally any feature should work for all agenda views that the user
might want to use it for.  We want to reduce features that only work
in special cases, or that don't work in special cases.  Ideally.

Again, what I am talking about (your case might be different) is not
todo entries, but entries in general.

 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

IMO the user sets the sort for the daily/weekly agenda just as much as
for the others, and it is not always just by time, so it should be
possible to meet the user's expectations with any new feature there as
much as for other agenda views.

 would take some serious chin-scratching. But it would at least need to

I'm not sure why any agenda view can't use these features.  Certainly
for my goal, but presumably for yours also?

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

Usually not, but I'd want it to be an option for any new feature, for
the sake of people who do.  Otherwise they would wonder why it isn't
working, post to the ml, etc.

 I think we have similar goals, I just ended up with something a little

I'm reaching the opposite conclusion :).  But I agree that if things
are similar, they should be made the same with parameters.  So if they
are similar, go for it!

 haven't implemented any dimming yet, and it would be just as easy to dim
 ancestors as children (both options could be provided).

OK, understood.

 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

olpaths are another way.  You might be able to collect them and put
them on the entries in the agenda as a text property for efficiency.
Or something.  Then skipping can do its own thing without being mixed
up with this stuff.

Just stuff to possibly consider.

Samuel

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

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:


[...]

 My goal is simple: go through entries in the already-built agenda and
 dim anything that has a descendent in the same agenda.

 Hierarchical sorting is for the future.  And it is undesirable if you
 do not have the horizontal real estate to indent.

Okay, what you want is simpler than I had assumed. My goal isn't really
to make something that dims ancestors, though: it's to give users a
number of choices for indicating hierarchical relationships between
entries in agenda views. That ought to encompass your needs, but it
probably will end up being a little more complicated.

[...]

 I'm not sure why any agenda view can't use these features.  Certainly
 for my goal, but presumably for yours also?

The main problem is that the codebase is very scattered, and there are a
large number of different functions that produce and display agenda-like
entries. To make this (for whatever value of this) work for all agenda
views, it will take quite a bit of poking about, and making little
design decisions. I want to make sure that the general strategy is
acceptable before I put that work in.

Eric

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

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

[Eric Abrahamsen]

On Sun, Sep 11 2011, Samuel Wales wrote:

 Eric,

 I'm starting with the easiest use-case: attaching a level text
 property to each TODO. I'm trying to do this for TODOs produced by

 This might or might not solve all your needs, but one option for
 finding ancestors is to simply grab the olpath for each agenda line.
 Then you can compare pathname components.  For example /a/b is an
 ancestor of /a/b/c/d/e.

Thanks for keeping an eye on this! I had moved from calculating level to
calculating path, and that looks like it will solve the basic issue. Now
I'm fiddling with edge cases, and distinguishing todo blocks from agenda
blocks in custom views, and… and…

Getting close though!

E

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

[Samuel Wales]

Eric,

 I'm starting with the easiest use-case: attaching a level text
 property to each TODO. I'm trying to do this for TODOs produced by

This might or might not solve all your needs, but one option for
finding ancestors is to simply grab the olpath for each agenda line.
Then you can compare pathname components.  For example /a/b is an
ancestor of /a/b/c/d/e.

That would be sufficient for dimming ancestors.  But you might be
wanting to do something fancier.

Samuel

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

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

[Eric Abrahamsen]

On Wed, Aug 24 2011, Samuel Wales wrote:

 Here is a different solution.  It is from my notes from long ago.

 To me, one issue with indenting is that you expect the previous line
 to be a direct parent, analogously with the outline.  This conflicts
 with sorting and non-child descendents.

 If you sort, you can't take advantage of the feature and have it look
 right.  If it's not a direct child, you can't take advantage of it
 either because you either confusingly indent too much or modify the
 semantics.  Also, indenting interferes with putting as much
 information on the line as possible.  Those with large fonts or small
 (e.g. mobile) displays value the real estate.

 ===

 Here is an alternate, which might or might not satisfy the OP's needs
 tangentially, but might spark discussion in either case.

 One feature I have long wanted, but have not been able to implement,
 is to dim (or color) any agenda entry that has a descendant in the
 same agenda view.

 ===

 This is a completely different thing from dimming blocked
 tasks, because it only looks at other tasks in the same
 view, and doesn't care about todo keywords.

 The pseudocode is this:

   loop for i in all headlines in agenda (even a combined agenda)
 if i has an ancestor in agenda, dim that ancestor


This is interesting, and certainly could be a potential display option.
It still sort of begs the question of how to get level and/or
child/ancestor information attached to the collected TODOs as they're
being produced for the agenda views.

I'm starting with the easiest use-case: attaching a level text
property to each TODO. I'm trying to do this for TODOs produced by
`org-todo-list' (used by the ?t and ?T dispatch commands) and
`org-tags-view' (used by the ?m and ?M dispatchers). The former employs
`org-agenda-get-day-entries' and then `org-agenda-get-todos' to find its
TODOs, the latter uses `org-scan-tags'.

I've put code into both `org-agenda-get-todos' and `org-scan-tags' that
attaches a level property to outgoing TODOs, and so far that's working
okay. A smarter thing to do would probably be attaching a parent
property that points to the parent headline. Different display options
could then use that information to munge the agenda display in different
ways: dimming, indenting, prefixing a path, etc.

Anyway, I'm just thinking out loud here! If the org gurus have any
pointers or warnings, that would be appreciated…

Eric

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

[Samuel Wales]

Here is a different solution.  It is from my notes from long ago.

To me, one issue with indenting is that you expect the previous line
to be a direct parent, analogously with the outline.  This conflicts
with sorting and non-child descendents.

If you sort, you can't take advantage of the feature and have it look
right.  If it's not a direct child, you can't take advantage of it
either because you either confusingly indent too much or modify the
semantics.  Also, indenting interferes with putting as much
information on the line as possible.  Those with large fonts or small
(e.g. mobile) displays value the real estate.

===

Here is an alternate, which might or might not satisfy the OP's needs
tangentially, but might spark discussion in either case.

One feature I have long wanted, but have not been able to implement,
is to dim (or color) any agenda entry that has a descendant in the
same agenda view.

===

This is a completely different thing from dimming blocked
tasks, because it only looks at other tasks in the same
view, and doesn't care about todo keywords.

The pseudocode is this:

  loop for i in all headlines in agenda (even a combined agenda)
if i has an ancestor in agenda, dim that ancestor

Motivation is that sometimes I mark a task as important (or
any other tag), and mark its child as important.  When I look
at the agenda view for important items without inheritance, I
am less interested in the parent because there is something important
in a descendent.

But when B is done, I am interested in A again.  I don't want to
manipulate tags.  I
just want to have both there all the time in the agenda, but
one dimmed.

  * deal with company A :important:
* call B at company A :important:
* call C

===

Hope this idea helps the OP's indenting need or similar ones.

Samuel

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