From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views) Date: Sat, 24 Sep 2011 21:55:47 -0700 Message-ID: References: <87mxez8eze.fsf@ericabrahamsen.net> <87ipoyyuoq.fsf@ericabrahamsen.net> <87sjnmoxp0.fsf@ericabrahamsen.net> <87ty81nugh.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:37171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7gko-0003sp-C3 for emacs-orgmode@gnu.org; Sun, 25 Sep 2011 00:55:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7gkm-0007e9-Q6 for emacs-orgmode@gnu.org; Sun, 25 Sep 2011 00:55:50 -0400 Received: from mail-gw0-f41.google.com ([74.125.83.41]:49548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7gkm-0007e5-Mg for emacs-orgmode@gnu.org; Sun, 25 Sep 2011 00:55:48 -0400 Received: by gwaa12 with SMTP id a12so5946766gwa.0 for ; Sat, 24 Sep 2011 21:55:48 -0700 (PDT) In-Reply-To: <87ty81nugh.fsf@ericabrahamsen.net> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Abrahamsen Cc: emacs-orgmode@gnu.org On 2011-09-24, Eric Abrahamsen 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.