From: Samuel Wales <firstname.lastname@example.org> To: Eric Abrahamsen <email@example.com> Cc: firstname.lastname@example.org Subject: Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views) Date: Sat, 24 Sep 2011 21:55:47 -0700 [thread overview] Message-ID: <CAJcAo8sbOKyne+0s4COe6UN25zEVoWeeSSkitpY7OfWj9tNf3A@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On 2011-09-24, Eric Abrahamsen <firstname.lastname@example.org> 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.
next prev parent reply other threads:[~2011-09-25 4:55 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 2011-09-25 4:55 ` Samuel Wales [this message] 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 \ --in-reply-to=CAJcAo8sbOKyne+0s4COe6UN25zEVoWeeSSkitpY7OfWj9tNf3A@mail.gmail.com \ --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).