emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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.

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