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