It's always good to see Org mode flagged up (though it gets a
surprising amount of love on HN).
I use Org more or less constantly, and I'll take this opportunity to
note an Org-related observation that I've been mulling over for a bit.
It's apropos of nothing, but then so was this submission :)
The observation has to do with how new Org users get to know the
system. The whole thing can seem pretty daunting, especially when you
look at some of the
examples of TODO setups (http://doc.norang.ca/org-mode.html) in the
wild. Pretty crazy.
My nutshell advice for new users is: in the beginning, you should
emphasize learning to use Org's tools effectively, rather than
spending time organizing your Org files structurally. The initial
impulse is: I'm going to make this file look just like my brain (or my
project). Instead, learn to use the agenda commands, so that you can
make the Agenda look like your project, not the file.
A couple of reasons for this: If you start out trying to make
structure (and I'm also talking about very complicated TODO keyword
flowcharts), you're going to get it wrong, and it's going to be a pain
in the butt to fix. Learning Agenda commands, on the other hand, will
always provide you with more flexibility, not less. It will give you
the power to handle new situations easily, and to narrow your focus
with ease. (Actually the same principle applies to Emacs usage in
general.)
For instance: I do a fair amount of event and conference management,
little four/five day things. In the beginning, I started by making Org
files where each day was a heading, and then the various events lived
under the various headings. This meant that, if events got changed
around, I had to go to the file and refile, which isn't terrible, but
is a pain.
Instead, I now have no day-based headings at all, just a pile of
potential events with timestamps. The Agenda organizes things into
days for me. If I need to reschedule something, the Agenda provides
more than ample commands for shifting dates by hour/day, or simply
entering a new date altogether.
Dump everything in one file, all top-level todos. Use the built-in
TODO keywords. Learn to make timestamps, and schedule/deadline
cookies. After you're good at that, maybe consider using tags (but
maybe don't). Spend the rest of your time learning how the Agenda
commands work. Stay in the Agenda, and if you must look at a file, do
it with <SPC> on the headline (followed by "o" when you're done), or,
if you must, <TAB>. Resist the temptation to futz with your files at
all, until some real need begins to emerge from daily usage. If you
hold out until the annoyance is killing you, it should be very clear
what needs to change, and how, and you're unlikely to do something
that you'll regret later.
(I should note that I use Org for two general types of work: one is
document authoring, the other is todo/agenda management. The above
basically only applies to the latter.)
Learn to impose dynamic, temporary structure on your agenda, rather
than imposing static, one-time structure on your files.
> Stay in the Agenda, and if you must look at a file, do it with <SPC> on the headline (followed by "o" when you're done)
I've been using Org for several years, but I never knew about the SPC/o combination in the Agenda (I recently discovered TAB). Thanks for sharing that!
Another great agenda feature is bulk editing. Mark entries with `m`, and then use `B` to act on them. Bulk refiling is really handy! Scatter is a neat feature too.
Also, I've come to really like indirect buffers (`org-tree-to-indirect-buffer`). You might also find this useful:
(defun ap/org-agenda-goto-heading-in-indirect-buffer (&optional switch-to)
"Go to the current agenda headline in an indirect buffer. If SWITCH-TO is non-nil, close the org-agenda window."
(interactive)
(if switch-to
(org-agenda-switch-to)
(org-agenda-goto))
(org-tree-to-indirect-buffer)
;; Put the non-indirect buffer at the bottom of the prev-buffers
;; list so it won't be selected when the indirect buffer is killed
(set-window-prev-buffers nil (append (cdr (window-prev-buffers))
(car (window-prev-buffers)))))
(defun ap/org-agenda-switch-to-heading-in-indirect-buffer ()
(interactive)
(ap/org-agenda-goto-heading-in-indirect-buffer t))
Seriously, that's the side of things where Org is meant to get out of your way, not provide you with a bunch of flashy tools. Learning to create and manipulate headings (move up, move down, indent, outdent) should take you all of fifteen minutes. Add plain lists, if you like, and footnotes. That's about it.
Where things do get complicated is when you start exporting documents, and realize it would look a bit better if this bit were just a bit different, and then... rabbit hole. But all that stuff, while fiddly, is pretty straightforward, it doesn't have the emergent complexity of agenda handling.
I use Org more or less constantly, and I'll take this opportunity to note an Org-related observation that I've been mulling over for a bit. It's apropos of nothing, but then so was this submission :)
The observation has to do with how new Org users get to know the system. The whole thing can seem pretty daunting, especially when you look at some of the examples of TODO setups (http://doc.norang.ca/org-mode.html) in the wild. Pretty crazy.
My nutshell advice for new users is: in the beginning, you should emphasize learning to use Org's tools effectively, rather than spending time organizing your Org files structurally. The initial impulse is: I'm going to make this file look just like my brain (or my project). Instead, learn to use the agenda commands, so that you can make the Agenda look like your project, not the file.
A couple of reasons for this: If you start out trying to make structure (and I'm also talking about very complicated TODO keyword flowcharts), you're going to get it wrong, and it's going to be a pain in the butt to fix. Learning Agenda commands, on the other hand, will always provide you with more flexibility, not less. It will give you the power to handle new situations easily, and to narrow your focus with ease. (Actually the same principle applies to Emacs usage in general.)
For instance: I do a fair amount of event and conference management, little four/five day things. In the beginning, I started by making Org files where each day was a heading, and then the various events lived under the various headings. This meant that, if events got changed around, I had to go to the file and refile, which isn't terrible, but is a pain.
Instead, I now have no day-based headings at all, just a pile of potential events with timestamps. The Agenda organizes things into days for me. If I need to reschedule something, the Agenda provides more than ample commands for shifting dates by hour/day, or simply entering a new date altogether.
Dump everything in one file, all top-level todos. Use the built-in TODO keywords. Learn to make timestamps, and schedule/deadline cookies. After you're good at that, maybe consider using tags (but maybe don't). Spend the rest of your time learning how the Agenda commands work. Stay in the Agenda, and if you must look at a file, do it with <SPC> on the headline (followed by "o" when you're done), or, if you must, <TAB>. Resist the temptation to futz with your files at all, until some real need begins to emerge from daily usage. If you hold out until the annoyance is killing you, it should be very clear what needs to change, and how, and you're unlikely to do something that you'll regret later.
(I should note that I use Org for two general types of work: one is document authoring, the other is todo/agenda management. The above basically only applies to the latter.)
Learn to impose dynamic, temporary structure on your agenda, rather than imposing static, one-time structure on your files.
Here endeth the (unasked-for) lesson. :)