An excuse to use Emacs - this blog

If I’m being honest, I created this blog as an excuse to mess with Hugo and generating its Markdown files using Org mode.

I love me a static website, but I grow lazy and sometimes posting this way is just too much work, ya know? I’ll keep it around, but it’s likely that most of my posts will be made over at Coping Mechanism.

DHH on Apple and Spy Pixels


Apple has announced they'll follow our lead, and block those abusive little beacons this Fall. Bam.

While I suppose it’s possible that Apple saw what HEY was doing and thought, “Now there’s a good idea, we should do that!”. Possible, but I think maybe DHH is overestimating Basecamp’s influence.

New theme - CodeIT

The theme I was using here had an annoying behavior, so I got a new one.

My original theme, based on Even, did this thing where the content would jump just a little whenever the page loaded. It was driving me nuts, and I couldn’t figure out what was causing it, so I punted and forked CodeIT.

You may recognize CodeIT because it was what I used before archiving a few months ago.

Creating a digital index for my paper notebooks

One of the few valid arguments against paper notebooks is that they are more difficult to search than digital notes. Fine, I’ll concede that one. But I’m working on a patch for that.

Rather than trying to digitize/OCR everything, I’ve decided that a simple index of topics should be sufficient. While rummaging around for ways to do this, I found Soren Bjornstad’s mindex. Mindex is a small Python script that takes some input and generates a concise LaTeX-then-PDF index based on a simple text (.mindex) file.

Here’s a section of the .mindex file for my current notebook:

Books       32
Charlie     37-41
COVID-19    23,32,39
Creativity  43
Crypto      35
Devices     34
Fusionary   21, 26
Health      26,41
Investing   26
Journaling  21,37

It’s a tab-delimited file with Topic->Pages->Sort Key. The third column, Sort Key, allows for tweaking of where each entry ends up in the final index. I’ve not needed to use that yet, though.

I wanted a few minor formatting changes so I forked Soren’s repo to and tweaked it a little. Here’s the current output:

Figure 1: Index sample

Figure 1: Index sample

I think it looks nice. LaTeX is awesome. I’m planning to update the index once a month or so. I just did it for May and it only took about 10 minutes. That’s not too high a price to pay for the ability to find things more quickly. Once a notebook is complete I may print a copy and insert it right into that notebook.

I’m still thinking about how to best manage this, but it’s a nice start.

Pilot Custom 823 Fountain Pen

It’s been a while since I bought a new fountain pen. This is about the Pilot Custom 823.

Literally every review I’ve read says the same things: “It’s not a looker, but what a great writer!” I can only resist that kind of consensus for so long, so I bought one. I have the “smoke” color with a fine nib. I ordered it from JetPens for $270. I’d say this puts it well into significant purchase territory, so I was very excited when it arrived. I’ve been journaling quite a lot recently and was looking forward to spending time with what reviewers call one of the best every day writers.

I’d like to tell you that it was love at first write, but that hasn’t been the case. The pen looks fine, if a little boring. I didn’t get it for its looks, so I don’t mind. The pen feels very good in hand, too. This is important. It’s not too heavy or unbalanced, either with the cap posted or not.

It’s a vacuum filler, which is apparently unusual but I’m not sure why, as it’s super easy to fill. It holds a lot of ink, too. It does make it more difficult to switch inks, but I don’t switch often so I don’t mind.

So what’s not to love, then? Well, so far I don’t love how it writes. I bought the pen to write with and not look at, so this is a problem. It’s been inconsistently scratchy and has skipped more often than is normal. At first I thought of it simply as “feedback” but it’s worse than just feedback. It feels dry. I’m left-handed, so any scratchiness in a pen is amplified. It’s disappointing. Since the ink chamber is sealed from the feed, it’s recommended to keep the plunger unscrewed (at the finial) while writing. I’m doing that, but it doesn’t make a significant difference.

It’s possible I got a bum copy, but I’m loathe to ship things back and wait so I have a few things I’d like to try first.

First, I will run it with some different inks. I typically use one of the quick-drying Nooder inks like Bernanke Blue, but maybe something “wetter” will fare better.

I could try different paper, but that’s not helpful since I have no interest in anything other than the Leuchtturm notebooks for most writing. I did write a little in the Hobonichi Techo and things were better. Tamoe River paper is the greatest, but I don’t like most of the notebooks that use it (other than the Techo, that is, but I don’t journal in the Techo.)

If these don’t help, I’ll advance to something more drastic, such as physically spreading the nib by pulling it apart at the shoulder, just a little. If that doesn’t help with the flow, I’ll send it to a “nibmeister” for tweaking. I normally would scoff at doing that, but years ago I sent my Pelikan to Richard Binder and it came back flawless. Still is.

I don’t want to doubt the nearly unanimous consensus about the Pilot Custom 823, so I am still going with the theory that mine needs some work. Still, I sure hope I can fix the issue and that the pen lives up to its stellar reputation.

Added Goatcounter analytics

Since Goatcounter is free for non-commercial use under 100,000 views per month, I thought I’d give it another try.

I’ve been using Plausible Analytics for a long time and have no issues. Still, Goatcounter is free and at least as privacy-minded and who am I not to at least try it?

UPDATE 2021-06-05: I still find Goatcounter too hard to parse, so I’m removing it.

Running Doom and Nano emacs at the same time using Chemacs

Most of the time I use a Doom Emacs configuration, but sometimes I feel like testing something new. I’ve been enamored by Nano Emacs lately, but there’s no way I’ll switch to it permanently.

Today I learned about Chemacs.

Chemacs 2 is an Emacs profile switcher, it makes it easy to run multiple Emacs configurations side by side.

So I configured Chemacs and added profiles for my default Doom config and also one for Nano. This is crazy, but I can now run both configurations at the same time!. Here’s a screenshot. The left window is Org-journal in Nano and the right window is my org-mode configuration in Doom.

Here’s a helpful video showing how it all works:

I no longer enjoy writing code

I was never a great programmer, but I was a pretty good developer. By this I mean that I could solve real problems for people by writing software.

I don’t enjoy coming up with clever algorithms and I hate math. But most development is just storage and retrieval of data, and I like storing, retrieving, and displaying data.

But I no longer enjoy writing code. I’m not sure why. I think maybe it’s because in recent years at Fusionary, my role moved away from programming. This meant I no longer kept up with details of the latest techniques and trends. I knew what was being done and (most of the time) why, but the ability to actually do any of it got away from me.

Now that I’ve lagged so far behind “state of the art,” it feels impossible to catch up. I’ve made furtive attempts, but end up a frustrated old man yelling at clouds. I don’t think this is all my fault. I believe things have become way over-complicated and overwrought, caused by too many devs reading blog posts about how Facebook or Pinterest does things and then assuming that’s the way everyone should do things. Too clever by half.

But, I admit that the way I did things isn’t nearly good enough today. Maybe that’s why I give up so quickly. It’s not fun like it was in the Good Old Days™. At least it’s not fun for me.

Front-end web dev is, to me, mired in frameworks and “best practices” that maybe shouldn’t be. Maybe it’s not that I don’t like writing code, maybe it’s the bog-standard JavaScript-riddled front end development I don’t like. Perhaps I should look into Ops, or ML or AI or AR. Maybe learn Go or Clojure or, if I’m feeling feisty, Rust.

Or maybe instead I should just get that paper route I always wanted.

Local theme development when using Hugo Modules

Recent versions of Hugo prefer the use of Go Modules for managing themes. This is new and a little weird to me, but I’m slowly beginning to understand it. I’m documenting the process here so I don’t forget.

I’ve forked an original theme (Even) for use here. To tell Hugo where the theme is, I added the following to my site’s config.toml…

    path = ""
    disabled = false

With this in place, running hugo mod get will do its magic and use the code in the referenced Github repo as the site’s theme. By default, modules seem to mount in “themes/”, so this just works. It feels a little magic because nothing actually lives in “themes/”. This took some getting used to.

But with the site using code from a (remote) repo, how do I work on the theme locally? I don’t want to have to make a change in a local repo, then commit-push-get to test every little change. After some digging, I learned that Hugo has a “replacements” feature in modules.

Replacements allow Hugo to temporarily use other mounts/modules. I only want to use my local copy of the theme while doing development, so I added the replacement as an environment variable in .zshrc like so:

export HUGO_MODULE_REPLACEMENTS=" -> /Users/jbaty/dev/hugo-theme-even"

Now, when running hugo serve locally, it picks up my local repo automatically, but server builds will use the “real” repo from Github. Clever.

And so far, all of this “Just Works” when deploying to Netlify.

UPDATE: I’ve learned that in order for Hugo/Netlify to pick up changes to the remote theme repo, there must be a “release” created in Github. Also, I’ve changed the build command from just `hugo` to `hugo mod get && hugo` otherwise it doesn’t always seem to pick up the new theme release.

Grok TiddlyWiki

Soren Bjornstad has recently released the first edition of Grok TiddlyWiki and it’s terrific.

Grok TiddlyWiki is a textbook that helps you build a deep, lasting understanding of and proficiency with TiddlyWiki through a combination of detailed explanations, practical exercises, and spaced-repetition reviews of prompts called takeaways.

A chief complaint about TiddlyWiki is that it’s difficult to learn. This is not unfounded. The documentation is complete, but hard to parse and there are few resources for actually learning TiddlyWiki. Grok TiddlyWiki is a fantastic resource and if you’re even remotely interested in learning more about TiddlyWiki, it’s highly recommended. My goodness, TiddlyWiki is amazing.