From: Eric Abrahamsen <email@example.com> To: firstname.lastname@example.org Subject: Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views) Date: Sun, 25 Sep 2011 11:59:10 +0800 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CAJcAo8s6=myZaJWGxYdTZ=QPq=OiLKjfeyHEBHAqgrYudhjmBw@mail.gmail.com> 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 <firstname.lastname@example.org> 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)
next prev parent reply other threads:[~2011-09-25 3:59 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-08-23 18:40 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 [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this 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).