From: Carsten Dominik <dominik@science.uva.nl>
To: Samuel Wales <samologist@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: outline-agenda sorting consistency
Date: Wed, 4 Mar 2009 12:53:45 +0100 [thread overview]
Message-ID: <E8185852-EB04-429C-8992-DA3837DA6229@uva.nl> (raw)
In-Reply-To: <20524da70903022009m618d7ef2u4c85a1fa5de55bea@mail.gmail.com>
On Mar 3, 2009, at 5:09 AM, Samuel Wales wrote:
> Hi Carsten,
>
> On Thu, Feb 19, 2009 at 12:22, Carsten Dominik
> <dominik@science.uva.nl> wrote:
>>> 1) priority faces are settable in the agenda. perhaps
>>> they could be so in the outline also.
>>
>> This seems more confusing than useful to me. In the agenda,
>> all the tasks are together, so it does make some sense to
>> change fonts. In the outline, I would find it confusing.
>> Are there any other opinions on this?
>
> I'll try to provide more detail for at least my case.
>
> I would not set the face for the whole headline, just the
> priority tag itself. I actually find the agenda faces,
> which often set the entire headline, to be confusing.[1]
>
> I would not propose to change the default.
>
> For me [#C] and [#A] look alike and it is hard to
> distinguish them based on the single letter. I basically
> stopped using C because I kept (mis)perceiving it as
> important. (I don't use B because it is the same as blank.)
> What I would do is set C to show in something like (but not
> the same as) the done todo kw face, and A to show in
> something like the todo face. This tells me to pay
> attention less and more, respectively. Others would
> semioticize (so to speak) differently.
Hi Samuel,
you can now et faces for each priority, using the variable
org-priority-faces, in a way similar to the todo-keyword faces,
and the tag faces. Just note that the car in this alist must be
a character, not a string.
>
>
>>> 2) sorting strategy is settable in the agenda. perhaps it
>>> could be settable in the outline also. they could
>>> share code.
>>
>> To be honest, I never sort the outline, except in rare cases.
>> I would be interested how people use this to get a better case
>> for changing this.
>
> I would use it to keep high urgency and -priority tasks at
> the top and done tasks at the bottom.
>
> Also, I sometimes have a large list of disorganized tasks.
> The tasks need todo state specification, tagging, priority
> setting, refiling, turning into a plain list, etc.; and
> sorting seems the best way to focus the organizing. I can
> only do a little at a time, and can't predict when I can do
> it, so having it sorted allows me to immediately see gaps.
> Like "this is too urgent to be among the non-urgent tasks".
> Then I can return to it later without having to
> refamiliarize myself with the whole list.
>
> I can more easily isolate the high priority and high urgency
> stuff that isn't done, then organize only that. After
> dealing with metadata, I can make the hierarchy deeper by
> ontology.
>
>
> Having it work like org-agenda-sorting-strategy would allow
> the same sorting in both places.
>
> Here is how I might do it, were the facility to exist:
>
> - done-ish and unimportant stuff at the bottom, important
> stuff at the top, and uncategorized nodes (i.e. blank
> todo state, no priority, no urgency) in the middle.
> - alphabetical order for nodes with the same weight
> - to calculate the weight of a node:
> 1) priority a is worth +1000
> 2) urgent tag gets +1000
> 3) now tag gets +500
> 4) todo-ish states (todo, next) get +100
> 5) /blank todo state/ gets 0
> 6) zombie states (wait etc.) get -100
> 7) someday tag gets -500
> 8) priority c gets -1000
> 9) done-ish states (done, moot) get -3000
> - example: an urgent todo would have a weight of 1100.
> when it is marked done, it would have a weight of -2000.
Outline sorting can be done using a user-defined function,
so in principle this should be possible..... It is on my list,
but not with high priority....
> This is especially useful for long confusing lists.
>
>> One of the basic principles in Org is that in the notes files,
>> tasks are in context. In the agenda, things are re-arranged
>> and sorted. That is why there is a complex sorting strategy
>> in the agenda, but not in the outline.
>
> The agenda is wonderful for other stuff, but for me it is
> not an editing mode per se. I have never been able to use
> the agenda for full control over the org file, as some
> people are able to do. For me (at least on my computer) it
> is slow.
What is "slow". Maybe we can improve things?
> Arbitrary editing is not possible. The keys that
> work are often different from the ones I use in the outline.
> If I define a key in the outline, I have to figure out how
> to define it in the agenda (haven't yet).
(add-hook 'org-agenda-mode-hook
(lambda ()
(define-key org-agenda-mode-map "key" 'command)))
- Carsten
> I find
> manipulating windows to be cumbersome, especially since for
> accessibility reasons I have no option but to use very large
> fonts that make split windows show very few lines (I
> typically never split windows). I usually can't see all the
> tags in the agenda because there are not enough columns. I
> can't scroll the other window in follow mode. Extra
> keystrokes are required to organize things. I can't easily
> create an arbitrary outline view of all tasks under a node
> with it. I can't rearrange and sort as I would in the
> outline.
>
> So for me, while the agenda is indispensable, it is only for
> showing an agenda view and occasionally jumping to a place.
> Not for arbitrary sorting and organizing.
>
> Just a different perspective / user experience. I hope it's
> useful in some way at least.
>
>
> [1] Especially since some elements get recolored
> (refaced) from the way they are in the outline. e.g. done
> todo kw showing up as todo face or tags being recolored.
> Might be bugs or might be overloading (because there is
> deadline and scheduled information being added to the
> information that is already in the headline). A possible
> solution is to reface just the category, or to have a single
> column for status, or something like that. I haven't
> thought about it deeply enough to comment further.
next prev parent reply other threads:[~2009-03-04 11:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-11 5:36 outline-agenda sorting consistency Samuel Wales
2009-02-19 19:22 ` Carsten Dominik
2009-03-03 4:09 ` Samuel Wales
2009-03-04 11:53 ` Carsten Dominik [this message]
2009-03-14 3:18 ` Samuel Wales
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=E8185852-EB04-429C-8992-DA3837DA6229@uva.nl \
--to=dominik@science.uva.nl \
--cc=emacs-orgmode@gnu.org \
--cc=samologist@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).