For the Wynn - My BASB Implementation in Org Mode v2023-06

The meat and potatoes of the series! The stuff you’ve probably been waiting for!

Rather than dump the entirety of my init folder on you, I’ve opted to give a more narrative explanation of how the system came to be. If you are unclear about anything, please reach out on the socials and I’ll do my best to clarify.

Reminder: I use the term BASB to refer to the solution we’re building in Org.

I’m sure I’ll update this page more than a few times, but expect I’ll write a new version after enough time passes.

Global Configurations

There aren’t that many global configurations I want to call out at the top. Generally, I write my init file in org, add packages and comments that I want to try, and add in commands I want to keep handy to my general.el keymap.

That said, there is one thing I want to encourage anyone considering org to take a look at: you should reverse the insert order of headings so that new entries come in at the top… a “reverse cron” approach to insertion if you will… rather than the default of appending to the bottom.

(setq org-reverse-note-order t)

I’ve found that this approach leverages the fact that we tend to want more recent things more at hand than older things. Plus if you stick wth the system for a while, appending to the bottom often entails a lot of scrolling.

Your mileage may vary, but worth noting.

BASB: Beginning with the End in Mind

I find that the nature of BASB creation inclines people to focus on the BASB as the target output. But that’s of course, not the real goal. The real goal is to figure out what other stuff this new tool/practice enables. Keeping that in mind, I find I can’t talk about the thing without talking about what I use it for and want from it first.

As such, I will walk my setup through each of the target use cases I aim to solve. I’m sure it will evolve as I add more, but the needs here are what drive the system, not the system driving my needs.

My Target Use Cases

Journaling and Regular Reviews

This is the number one use case because creating a regular habit that uses the tool multiple times per day is key to really learning it. Journaling isn’t a technically complicated use case, just requiring some templates and a place to journal in the system that doesn’t require thinking about where the entry goes.

I took a cursory glance through various options inside of org, and opted for using org-roam’s dailies to handle this. I’ve used diary mode in the past, but I liked org-roam’s capture system that was tied to it, so I went that direction. I also use org-roam for other things which I’ll describe later, so that was a reasonable fit.

This does mean that I break my principal of a single org file almost immediately, since org-roam does separate daily files by default. However, experience has taught me that I never mess with these physical files themselves, so I think it’s fine. Putting journals in one file is also a surefire way of eventually causing a performance problem somewhere down the line. Might as well head that one off before we get there.

Additionally, I keep all my templates as org files in a sub-directory, ~/org-roam-repo/templates. I find using full org files much easier to visualize and edit rather than storing them as strings in my init file. I mean, I can only handle so many \n’s before my eyes cross… and I’m a person who likes regular expressions.

This also shows the first example of my principle for subdirectory use in org:

Prefer a flat, single directory where possible. Use sub-directories for programmatic separation of content as needed.

In this case, having a single template directory (no files of which are included in the org-roam index) makes them easier to find, refer to, and keep out of the way of other files in BASB.

The following templates apply to this use case:

Morning Journal

Evening Journal

Weekly Journal

Monthly Journal

Interstitial Journal

Daily notes themselves go in a special subdirectory, ~/org-roam-repo/journals. The same reason as above applies, in that org-roam expects a directory to work with for journals, and I find separating them out is easier for various completion frameworks to handle rather than co-mingling them with other files. After all, today’s journal is very relevant. Tomorrow’s much less so. Even less before that. And on and on… No need to have all the clutter if I don’t need it.

And with just that, we’ve got a perfectly serviceable digital journal that I can copy, paste, and link into/out of which I interact with each morning and night. Not bad for minimal effort (though I’ve implemented enough PKM’s to know this is an easy case).

A huge but not-so-obvious reason we tackle this use case first, is that daily journals create space for process that helps fill any gaps in the rest of our setup. With a simple checklist as part of my evening journal, I can remind myself to do all kinds of things at the end of the day.

Maybe I need to...