From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: About TODO state, tags and properties in Org-mode Date: Fri, 12 Oct 2007 19:03:31 +0200 Message-ID: <3646362372db54b34e7e52cc992d5328@science.uva.nl> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IgNvI-0001wy-9A for emacs-orgmode@gnu.org; Fri, 12 Oct 2007 13:03:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IgNvG-0001w2-KR for emacs-orgmode@gnu.org; Fri, 12 Oct 2007 13:03:39 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgNvG-0001vz-Fv for emacs-orgmode@gnu.org; Fri, 12 Oct 2007 13:03:38 -0400 Received: from korteweg.uva.nl ([146.50.98.70]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IgNvG-0005q4-3o for emacs-orgmode@gnu.org; Fri, 12 Oct 2007 13:03:38 -0400 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: org-mode list 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.