emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
@ 2011-08-23 18:40 Samuel Wales
  2011-08-24  7:07 ` Eric Abrahamsen
  0 siblings, 1 reply; 13+ messages in thread
From: Samuel Wales @ 2011-08-23 18:40 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-08-23 18:40 Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views) Samuel Wales
@ 2011-08-24  7:07 ` Eric Abrahamsen
  2011-09-10 21:02   ` Samuel Wales
  0 siblings, 1 reply; 13+ messages in thread
From: Eric Abrahamsen @ 2011-08-24  7:07 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-08-24  7:07 ` Eric Abrahamsen
@ 2011-09-10 21:02   ` Samuel Wales
  2011-09-12  9:30     ` Eric Abrahamsen
  0 siblings, 1 reply; 13+ messages in thread
From: Samuel Wales @ 2011-09-10 21:02 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-09-10 21:02   ` Samuel Wales
@ 2011-09-12  9:30     ` Eric Abrahamsen
  2011-09-24 13:51       ` Eric Abrahamsen
  0 siblings, 1 reply; 13+ messages in thread
From: Eric Abrahamsen @ 2011-09-12  9:30 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-09-12  9:30     ` Eric Abrahamsen
@ 2011-09-24 13:51       ` Eric Abrahamsen
  2011-09-24 13:55         ` Eric Abrahamsen
                           ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Eric Abrahamsen @ 2011-09-24 13:51 UTC (permalink / raw)
  To: emacs-orgmode

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 (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 org-agenda-todo-custom-ignore-p (time n)
   "Check whether timestamp is farther away then n number of days.
@@ -5785,12 +5810,18 @@ could bind the variable in the options section of a custom command.")
 
 (defun org-finalize-agenda-entries (list &optional nosort)
   "Sort and concatenate the agenda items."
-  (setq list (mapcar 'org-agenda-highlight-todo list))
-  (if nosort
-      list
-    (when org-agenda-before-sorting-filter-function
-      (setq list (delq nil (mapcar org-agenda-before-sorting-filter-function list))))
-    (mapconcat 'identity (sort list 'org-entries-lessp) "\n")))
+  (flet ((flatten (l)
+		 (cond
+		  ((null l) nil)
+		  ((atom l) (if (and org-agenda-before-sorting-filter-function
+				     (not (org-agenda-before-sorting-filter-function l)))
+				nil
+			      (list (org-agenda-highlight-todo l))))
+		  (t (append (flatten (car l))
+			     (flatten (if nosort
+					  (cdr l)
+					(sort (cdr l) 'org-entries-lessp))))))))
+    (mapconcat 'identity (flatten list) "\n")))
 
 (defun org-agenda-highlight-todo (x)
(let ((org-done-keywords org-done-keywords-for-agenda)
@@ -5926,6 +5957,10 @@ could bind the variable in the options section of a custom command.")
 
 (defun org-entries-lessp (a b)
   "Predicate for sorting agenda entries."
+  (when (consp a)
+    (setq a (car a)))
+  (when (consp b)
+    (setq b (car b)))
   ;; The following variables will be used when the form is evaluated.
   ;; So even though the compiler complains, keep them.
   (let* ((ss org-agenda-sorting-strategy-selected)

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-09-24 13:51       ` Eric Abrahamsen
@ 2011-09-24 13:55         ` Eric Abrahamsen
  2011-09-24 23:54         ` Samuel Wales
  2012-04-23 23:10         ` Bastien
  2 siblings, 0 replies; 13+ messages in thread
From: Eric Abrahamsen @ 2011-09-24 13:55 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 199 bytes --]

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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nestedtodos.diff --]
[-- Type: text/x-diff, Size: 6372 bytes --]

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 org-agenda-todo-custom-ignore-p (time n)
   "Check whether timestamp is farther away then n number of days.
@@ -5785,12 +5810,18 @@ could bind the variable in the options section of a custom command.")
 
 (defun org-finalize-agenda-entries (list &optional nosort)
   "Sort and concatenate the agenda items."
-  (setq list (mapcar 'org-agenda-highlight-todo list))
-  (if nosort
-      list
-    (when org-agenda-before-sorting-filter-function
-      (setq list (delq nil (mapcar org-agenda-before-sorting-filter-function list))))
-    (mapconcat 'identity (sort list 'org-entries-lessp) "\n")))
+  (flet ((flatten (l)
+		 (cond
+		  ((null l) nil)
+		  ((atom l) (if (and org-agenda-before-sorting-filter-function
+				     (not (org-agenda-before-sorting-filter-function l)))
+				nil
+			      (list (org-agenda-highlight-todo l))))
+		  (t (append (flatten (car l))
+			     (flatten (if nosort
+					  (cdr l)
+					(sort (cdr l) 'org-entries-lessp))))))))
+    (mapconcat 'identity (flatten list) "\n")))
 
 (defun org-agenda-highlight-todo (x)
   (let ((org-done-keywords org-done-keywords-for-agenda)
@@ -5926,6 +5957,10 @@ could bind the variable in the options section of a custom command.")
 
 (defun org-entries-lessp (a b)
   "Predicate for sorting agenda entries."
+  (when (consp a)
+    (setq a (car a)))
+  (when (consp b)
+    (setq b (car b)))
   ;; The following variables will be used when the form is evaluated.
   ;; So even though the compiler complains, keep them.
   (let* ((ss org-agenda-sorting-strategy-selected)

[-- Attachment #3: Type: text/plain, Size: 156 bytes --]



-- 
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.324.ge5d88)

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-09-24 13:51       ` Eric Abrahamsen
  2011-09-24 13:55         ` Eric Abrahamsen
@ 2011-09-24 23:54         ` Samuel Wales
  2011-09-25  3:59           ` Eric Abrahamsen
  2012-04-23 23:10         ` Bastien
  2 siblings, 1 reply; 13+ messages in thread
From: Samuel Wales @ 2011-09-24 23:54 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Hi Eric,

Looks like you put a lot of work into this.

Some comments:

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-09-24 23:54         ` Samuel Wales
@ 2011-09-25  3:59           ` Eric Abrahamsen
  2011-09-25  4:55             ` Samuel Wales
  0 siblings, 1 reply; 13+ messages in thread
From: Eric Abrahamsen @ 2011-09-25  3:59 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-09-25  3:59           ` Eric Abrahamsen
@ 2011-09-25  4:55             ` Samuel Wales
  2011-09-25  5:52               ` Eric Abrahamsen
  0 siblings, 1 reply; 13+ messages in thread
From: Samuel Wales @ 2011-09-25  4:55 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-09-25  4:55             ` Samuel Wales
@ 2011-09-25  5:52               ` Eric Abrahamsen
  0 siblings, 0 replies; 13+ messages in thread
From: Eric Abrahamsen @ 2011-09-25  5:52 UTC (permalink / raw)
  To: emacs-orgmode

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)

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2011-09-24 13:51       ` Eric Abrahamsen
  2011-09-24 13:55         ` Eric Abrahamsen
  2011-09-24 23:54         ` Samuel Wales
@ 2012-04-23 23:10         ` Bastien
  2012-04-25  6:25           ` Eric Abrahamsen
  2 siblings, 1 reply; 13+ messages in thread
From: Bastien @ 2012-04-23 23:10 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Hi Eric,

Eric Abrahamsen <eric@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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2012-04-23 23:10         ` Bastien
@ 2012-04-25  6:25           ` Eric Abrahamsen
  2012-04-26 13:44             ` Bastien
  0 siblings, 1 reply; 13+ messages in thread
From: Eric Abrahamsen @ 2012-04-25  6:25 UTC (permalink / raw)
  To: emacs-orgmode

On Tue, Apr 24 2012, Bastien wrote:

> Hi Eric,
>
> Eric Abrahamsen <eric@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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
  2012-04-25  6:25           ` Eric Abrahamsen
@ 2012-04-26 13:44             ` Bastien
  0 siblings, 0 replies; 13+ messages in thread
From: Bastien @ 2012-04-26 13:44 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Hi Eric,

Eric Abrahamsen <eric@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

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2012-04-26 13:43 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-23 18:40 Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views) Samuel Wales
2011-08-24  7:07 ` Eric Abrahamsen
2011-09-10 21:02   ` Samuel Wales
2011-09-12  9:30     ` Eric Abrahamsen
2011-09-24 13:51       ` Eric Abrahamsen
2011-09-24 13:55         ` Eric Abrahamsen
2011-09-24 23:54         ` Samuel Wales
2011-09-25  3:59           ` Eric Abrahamsen
2011-09-25  4:55             ` Samuel Wales
2011-09-25  5:52               ` Eric Abrahamsen
2012-04-23 23:10         ` Bastien
2012-04-25  6:25           ` Eric Abrahamsen
2012-04-26 13:44             ` Bastien

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).