π

UOMF: The Right Way to Use Org Mode

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.

Many people wonder how Emacs Org mode is used in "the right way".

Here is my short answer to that: There isn't one right way for using Org mode features.

If this is obvious to you, you can skip the rest of this article. If not, you really should read this until the end. It may answer many questions you probably do have in your head. Especially when you're rather new with the Org mode universe.

Of course, the same rationale is true for all kind of advanced software solutions that offer a certain level of flexibility to its users. However, my examples here are based on Emacs Org mode.

This versus That

There are many options users of Org mode are facing. This sections mentions only a few of them. I do give short examples where my current solution is placed within that universe of options.

Put Things into Headings Versus into List Items

Beginners are sometimes confused where they should write their information to. A simple example would be:

- Shopping trip
  - [ ] Bread
  - [ ] Sugar
  - [ ] Salad	  

... or ...

 * Shopping trip
 ** TODO Bread
 ** TODO Sugar
 ** TODO Salad	  

Both approaches are valid ones. There is no right or wrong. Categories such as "right" or "wrong" can only be discussed when you do have a clear understanding of your requirements.

My approach on lists versus headings is that whenever something should be potentially "addressable" (link-able), it is a heading.

This way, I do have workflows with a heading typically with a [2/5] progress cookie that contains a list of checkbox items and I do have a sub-hierarchy of linked headings per workflow I call projects.

Put Data into Property Drawers Versus Write Data in the Content

Property drawers are a nice way of working with structured data and meta-data.

For example, you can use column view to get a decent overview of properties for any sub-hierarchy.

Most of the time, I don't use properties for data outside of CREATED, ID, and links.

Large/Few Org Mode Files versus Small/Many Org Mode Files

One of the biggest ongoing discussion in the Org mode community is if you should have just a few Org mode files that are typically long or if you should go for a larger set of smaller files. The Zettelkasten approach is clearly an example of the latter.

My current Org mode files are rather long and not numerous. My agenda files are always open as buffers in my Emacs sessions.

Why Isn't There "the Org Mode Way"?

So why is it that people discuss "the Org mode way" all the time?

My explanation on this is that people are used to software solutions that impose a certain way of usage. For example, most closed source software products from corporations like Apple and Microsoft can only be used in one specific way when you do want to achieve something particular. They don't offer much freedom.

For many situations, this is not a huge problem. This can even be a huge advantage for novice users up to a certain level of expertise. This usually becomes an issue when you are moving from entry level while you become an advanced computer user. This is the time where you should think of switching to an advanced tool instead in order to support you in an optimal way.

Org mode is an example of a power tool, an advanced software solution that offers a wide range of freedom to its users. The downside is that you do have to invest time to get a certain level of experience in order to built your own solutions on top of this powerful toolset.

I often compare Org mode with an endless large box of LEGO bricks: It only depends on you which bricks you take out of this box and how you combine them in order to build something useful. And if there are two different Org mode users building a solution for a similar set of requirements, their solutions will most probably differ from each other.

The Org mode manual is no help here either for determining ways to build solutions. The manual is just a reference that mentions, e.g., that headings can be encrypted via OpenPGP and a simple tag but it doesn't explain all the options to use this neat feature to build a password management solution.

This is the reason why I introduced the Using Org Mode Features (UOMF) article series. I want to give a few examples how I am using Org mode features to help you to come up with solutions for your own requirements. And they will - most likely - be different from mine. This doesn't make my solution more or less "the Org mode way". It is just one possible solution to a given set of requirements.

As I wrote in my article on how to start with Org mode you will notice that when you are using Org mode for a longer period of time, you get a different point of view on so many things. First, you might as well be happy with lists and checkboxes. Then, you will find out that the syntax overhead of headings is acceptable in order to get advanced possibilities for todo management such as using more than two task states or tags. Your heading structure will change over time as your content grows. Your personal world is changing and so your digital world will most probably follow as well. At least I hope so.

Now you should understand why there can't ever be "the Org mode way of doing things" for anything that can not be considered as trivial any more.

Backlinks


Related articles that link to this one:

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