From: Carsten Dominik <dominik@science.uva.nl>
To: org-mode list <emacs-orgmode@gnu.org>
Subject: About TODO state, tags and properties in Org-mode
Date: Fri, 12 Oct 2007 19:03:31 +0200 [thread overview]
Message-ID: <3646362372db54b34e7e52cc992d5328@science.uva.nl> (raw)
About TODO state, tags and properties in Org-mode
In a recent message to emacs-orgmode, Richard G Riley asked for
more background about the concept of properties and their
relation to tags. Let me try to take a step back and explain
these concepts together.
Every node in an Org-mode outline tree is an /entry/. Due to the
outline structure of the document, the entry may have a parent,
and it may have children.
In order to function as a task manager, Org-mode assigns certain
qualities to entries. The most general way to assign qualities
are /properties/. Properties are a list of keyword-value pairs.
In Org-mode, properties are stored in a special block, called the
/property drawer/.
In principle, the concept of properties would be enough to handle
everything that a user might want to assign to an item. We could
have a "TodoState" property that captures the TODO state, a
"Priority" property that captures the priority, "Deadline",
"Scheduled", "Appointment" properties for dates and times, etc.
However, properties are a "heavy" concept. Keeping them in a
plain text file requires a block of text under each and every
entry, making even simple lists complex and heavy, and hiding
important state information. However, Org-mode was develloped
with the philosophy /Make simple things simple and hard things
possible/. Therefore[1], Org-mode has other concepts the assign
qualities to entries by adding small strings to the entry line
itself. These concepts are:
- The /TODO state/, a single word at the beginning of an entry
line. This can be viewed as a privileged property that can
have exactly one of a limited number of values. These values
are mutually exclusive and the TODO state of an entry is
uniquely determined. Also, the TODO state cannot be inherited,
i.e. it is independent of the states of the parent.
- The /priority/, indicated by a small cookie in the headline.
Again, this could also be a property, but it is nice to have a
way to use it in very simple lists. Just like the TODO state,
the priority is not inherited.
- /Tags/. These can be viewed as /boolean/ properties. They are
either true of false, set or not-set. Since TAGS are listed in
the valuable real estate in the headline itself, they are
always visible in in this way privileged. Tags are inherited,
i.e. if a parent has a certain tag, this tag also applies to
its children (at least you can use them like this, but you can
also localize tags fully to an entry by setting a variable).
So when should you use what?
- As a beginner, use just the TODO state and priorities.
- To categorize or to assign GTD contexts, use tags.
- Turn to properties if you need to assign a quality that has
many values. For example, when you find yourself creating tags
like release_1_1, release_1_2, release_1_3, it is time to
introduce your first property.
- Property are also used internally to store customization
parameters that should apply to only a part of the outline
tree, usually a subtree. For example, the CATEGORY property
defines the category of a (sub)tree.
I hope this makes things a bit clearer.
- Carsten
[1] OK, here I am lying. This is not something that happened by
design, but historically. First simple concepts like the TODO
states were implemented, tags and properties later. However,
this is exactly why Org-mode still feels light-weight. You
absolutely do not have to use the advanced concepts of tags and
properties if you only want a plain list or a TODO state.
Sometimes that fact that a piece of software has not been
designed top-down can work out in its advantage.
reply other threads:[~2007-10-12 17:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3646362372db54b34e7e52cc992d5328@science.uva.nl \
--to=dominik@science.uva.nl \
--cc=emacs-orgmode@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.