emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: emacs-orgmode@gnu.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: <87ty81nugh.fsf@ericabrahamsen.net>

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.


The Kafka Pandemic: http://thekafkapandemic.blogspot.com
I support the Whittemore-Peterson Institute (WPI)
Bigotry against people with serious diseases is still bigotry.

  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:

  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 \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=eric@ericabrahamsen.net \
    --subject='Re: Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)' \


* 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:


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