π

UOMF: Using Org Mode Categories Versus Tags

Show Sidebar

This is an article from a series of blog postings. Please do read my "Using Org Mode Features" (UOMF) series page for explanations on articles of this series.

Emacs Org mode does provide two basic features to assign shared topics to entities: Categories and tags. Users might get confused when to use categories and when to use tags for labeling things. This article explains the fundamental differences and gives my recommendations on when to use what. Although I don't want to duplicate too much content from the Org mode manual, there are few things I repeat.

Categories

Categories are a method for assigning single classifications. Each heading is part of exactly one category, not many.

There are three different ways of assigning categories from my point of view.

  1. Multi-file
  2. One per file
  3. Category per project within a file

When several Org mode files share a category, it's a multi-file category. This can be achieved by adding a file-variable #+CATEGORY: foobar. I'm using multi-file classification when I have several Org mode files for my business life but want to have one combined category for all of them. For this, I am using the category company for the files company.org (miscellaneous general todos), company_projectX.org (related to one specific project), company_projectY.org (related to a different project), and so forth.

If you do not tamper with manually assigning categories, Org mode is using the file name of the current file as category by default. For example, company.org results in the category "company" for all of its headings.

In case you need to have finer grained categories, you have the possibility to assign a category for any given sub-hierarchy.

Let's have a look at the following example structure of file company.org:

 * Project X
 ** TODO Contact Bill Gates
 ** TODO Make business
 * Project Y
   :PROPERTIES:
   :CATEGORY: ProjectY
   :END:
 ** TODO Find a business plan
 ** SOMEDAY Follow the business plan
 ** SOMEDAY Get rich	  

Here, the todos of Project X do have the default category "company", derived from the file name company.org. All todos within the Project Y hierarchy do share the category "ProjectY" instead because this is defined via the CATEGORY property in the drawer.

In my opinion, it makes sense to limit yourself to top-level or second-level headings for manually assigning project-related categories for most cases.

By default, your agenda shows categories as the first column. If you press the < key, your agenda is filtered according to the category of the line of your cursor. So if you press < when being on a line whose task is categorized with "ProjectY", your agenda now only shows tasks of this category, hiding everything else. You can remove this filter by pressing | - the vertical bar character.

By manipulating org-agenda-category-icon-alist you are able to assign icons to matching categories. Here is my current config related to this. It's not only visual candy, it allows you to recognize important categories with distinctive icons. I would not recommend to use icons for all categories, if you tend to use more than a handful.

I am sticking to the default categories (per file) mostly. Only for business purpose, I use a multi-file category. For very few large projects, I am not using properties for defining categories, I use tags.

Tags

Tags allow for multi-classification. A heading is able to have a set of assigned tags. Furthermore, a heading is able to inherit the combined set of all tags assigned to its parent headings, if activated - which I personally recommend.

I'm quite fond of multi-classification and I do have some personal background with it.

Learning how to tag is a complex process itself.

The most important tip I'd like to give you is keep the set of tags as small as possible. You lose many advantages of tags and your overview with hundreds of tags. If you tend to use many tags, you are probably better off with using full text search instead of tags.

Limiting myself to a set of generic tags is the reason I was referring to in this article, where I explain why I'm not using tags for each of my blog series.

In order to maintain a defined set of tags, you might create a file named tags.org which looks similar to this:

 # -*- mode: org; coding: utf-8 -*-

 #+TAGS: account advertisement agile android apple art article
 #+TAGS: austria automotive backup beverage bibtex bicycle blog book bug
 #+TAGS: cheatsheet clipart cloud cooking culture database debian
 #+TAGS: decentralization design diy documentation education emacs
 #+TAGS: email environment ethics events expiringdata fashion finance
 [...]	  

In every related Org mode file, you can include these tag definitions like #+SETUPFILE: tags.org somewhere at the top section. You now get the benefit of tag completion when assigning tags via C-c C-q.

You recognize these tags above from this page of public voit showing a tag cloud of my blog tags. Be aware that the size of the set of tags is contradicting my recommendation above. This is mainly because I started blogging without knowing about and following this rule. Therefore, most tags of the tag cloud of my blog are outdated.

For my non-blog tags, I tend to maintain a set of tags for contacts (approximately a dozen tags + @-tags for each contact). Larger projects (headings that contain multiple sub-todos) get their project tag. This way, I don't have to add context for tasks.

Let's have a look at this example:

 * [1/3] Setup desktop background slideshow      :desktopimages:
 ** DONE Locate potential image candidates
 ** STARTED Find out how to change background
 ** TODO Setup process	  

Although I named the last task simply "Setup process", I know what process is meant because my agenda displays its assigned and inherited tag "desktopimages". Without the tag, I'd probably have no idea what this task is about without looking at its content or context.

Each contact get his or her "@FirstnameLastname" tag as mentioned above. This gets quite handy when preparing for a meeting with colleagues. My business-related Org mode files contain a heading at the top of each file with templates like this:

 #+BEGIN_SRC elisp
 (org-occur (concat "\\(TODO\\|NEXT\\|STARTED\\|WAITING\\).*:@" "PeterGabriel:.*"))
 #+END_SRC
 #+BEGIN_SRC elisp
 (org-occur (concat "\\(TODO\\|NEXT\\|STARTED\\|WAITING\\).*:@" "GordonSumner:.*"))
 #+END_SRC
 #+BEGIN_SRC elisp
 (org-occur (concat "\\(TODO\\|NEXT\\|STARTED\\|WAITING\\).*:@" "JohnLennon:.*"))
 #+END_SRC
 [... one snippet/block for each colleague ...]	  

These are three independent code snippets which lets me quickly generate sparse trees with open tasks that are tagged with the corresponding name when invoked via C-c C-c. Somebody with lisp knowledge might find a clever way of providing this feature without the necessity of defining hard-coded blocks but using ivy/helm-based @-name tag completion instead.

For a different, more complex approach of using @-name tags and related workflows, read about org-secretary.el.

I, personally, am not using group tags at the moment although my config still holds some org-tag-alist fragments from the past where I was using them. There are certain situations where group tags, especially mutually exclusive tags, are a handy tool.

When to Use Categories, When Tags

I already mentioned above how I am using categories and tags. Basically, I am limiting categories to a minimum. Mostly by using the default: one category per Org mode file. Since I'm using a small set of Org mode files (most content is within two handful of files), categories are a good method for filtering my agenda.

My tags are considered a finer grained label mechanism. Still, I force myself not to use too many tags. They provide me context so that I don't have to have very long task descriptions. For contacts and collaboration, @-name tags help me to search or filter for people-related headings.

Please do also consider reading Logical Disjunct Categories Don't Work which covers this topic.


Related articles that link to this one:

Comment via email (persistent) or via Disqus (ephemeral) comments below: