After searching around on Reddit yesterday, I found a reference to one of my old blog posts and reposted it on my current blog: Of TiddlyWiki, Emacs, and Digital Gardens.

I’ve been considering writing Micro.blog explanations and instructions again for the last two days, and the thought process led me to my wiki, which is still linked from my About section. The wiki is how I wrote about Micro.blog in the past, as I was learning how to use it (again, here’s the Micro.blog section in my wiki).

You’d notice there’s an index to the right with a search option, and that the content titled “Micro.blog” opens in a segment surrounded by a narrow red border, which contains a an additional topics section at the bottom, which you can also open from the main index to the right if you select and expend Micro.blog there. This, in a nutshell, is why TiddlyWiki is ideal for this sort of documentation.

It makes sense to go back to the wiki if I want to write technical workflows that people can read, because it’s more suited for the task than blog posts. The topics are sorted by category, not date, and the interlinking system is designed to consume knowledge in a dynamic way that I can’t do on a blog1.

But the real issue doesn’t lie with where to put this information; that answer has been in my head. The problem is the time and energy, which I already talked about several times. Emacs and org-mode have been the way to go for a long time, and that’s not going to change. When I learn something, it goes in Emacs, because nothing can beat the speed I get out of those. Writing a draft in TiddlyWiki is painful compared to writing something inside Emacs.

The obvious solution is exporting from org-mode to TiddlyWiki, and this is also the heart of the problem. There’s no direct way to do that, really.

There are some packages to use (I believe the last one I used was tid-mode), but these are all several years old and come with some issues. TiddlyWiki is sophisticated and uses its own syntax; some of the more advanced functions require typing in directly. If you’re familiar with markdown and HTML, you’d know that markdown covers about 90% of what you need, but every now and then, you just have to go in there and enter some HTML code directly. It’s a similar concept.

Combine that with editing, ensuring that everything fits visually on a browser, committing and pushing changes to GitLab (which is where I have it hosted), and you’ve got yourself a level of friction that slows you down and requires time. As much as I’d love spending a good hour or two a day writing these things (I enjoy it, believe it or not), I just don’t have that. Even if I get some dead time at work to do something, I have to be on standby almost all the time, and emergencies that pull me away from whatever I was doing happen constantly. This is something I can deal with when I write a blog post, which has a rather simple process, but it’s harder to do when you work with TiddlyWiki, Emacs, and Images (because I have a lot of visuals to support the documentation).

At the end of the day this is all just whining. I need to just start. Yeah yeah, I know.

Footnotes

1: Emacs users would read this and ask why not just convert to HTML? Well I did that, and even better: I can upload my org files directly to GitLab. It supports the syntax and it’s nice to read, images included. With Denote, it’s even better, as I can include indexes (called dynamic blocks) inside my files. This is something I discussed in the past. But as nice as this is, it’s still not as good as the wiki for consumption for non-technical users who don’t visit GitLab regularly. The abilities that come with TiddlyWiki make it on a level of a published book or a manual, something I believe you can only fully understand if you experience it yourself.