Back to the Drawing Board: My New Blogging Setup

My last post in this blog was roughly three years and a half ago. That is a very, very long time with no new posts. In this post, I will make a quick recap on the issues my old setup had, how it blocked me from writing, and what the new setup is to try and fix these errors.

Blogging with nothing, and nothing only

In this very blog you can find a post called Blogging with Emacs, and Emacs only, where I explained how I was able to set my blogging workflow to use exclusively Emacs: from writing my posts using org-mode, to generate the static site using org-publish. This setup worked wonderfully for some time. I was able to go from writing to a static site in a few key chords.

There were some interesting quirks that I found much later. For example, publishing the site when a mode was not configured or evaluated resulted in no syntax highlighting for the source codes in the blog. That means that I needed Haskell in every computer and the mode evaluated if I wanted my Haskell posts to have proper syntax highlighting. This and other subtle inconsistencies made me think of setting the actual deploy of the site from a CI job: that way, I could keep a declared lists of tools that were needed in the environment, along with my Emacs configuration, so that the site was generated and uploaded to the FTP. On paper, that was by far my best option. In reality, I was absolutely unable to properly set up my configuration of Emacs so that the commands were properly evaluated. The generated code was wrong, if it was even able to generate the code.

That is because Emacs is not thought to be included in a CI job, and its configuration is very hard to be evaluated from scratch without any intervention. And that is simply because Emacs is a text editor, and a text editor should not be in a CI job generating static HTML. That was a tough pill to swallow.

However, the worst problem with this setup was the inherently fragility that I have found in complex Emacs configurations. After several packages updates, the setup stopped working altogether, and I did not write often enough to be able to pinpoint the cause fast enough to be comfortable. Even though I had some ideas, having to fix it every time I wanted to publish a blog resulted in me being less willing to write. At some point, I had yet another .emacs bankruptcy, and the blog configuration was such a mess that did not even make the cut. I was indeed locked out of my own website.

If the only tool you have is a hammer…

I love Emacs. I do. Just take a look at all my posts. A great deal of them are about Emacs. It is a beautiful piece of software, with a beautiful history, the richest environment of extensions and the fact that is configured using a Lisp dialect makes it altogether a work of art.

I love Emacs, that’s why I don’t really like telling this story. At some point, at work, we were designing a reference document recommending tools to get started to interns and juniors. The idea was something along the lines of “if you use $X for $TASK that’s great; if you don’t know where to begin, maybe try $Y first”. That way, we could ensure that everyone had a good knowledge of their tools, or at least a reference document to ensure the bare minimum to comply to the code guidelines. For these set of tools we were looking for the ones with the most useful and intuitive interface, requiring the minimum configuration effort and producing the results without getting into one’s way. One of the values for $TASK was actually text editing. Emacs was not even in the candidates, because… Well, I’ll write it again: “most useful and intuitive interface, requiring the minimum configuration effort”. Emacs is great once you design your Emacs, but their defaults are far from intuitive (maybe because Emacs is twice as old as most of the junior profiles we were aiming the document at).

One of the candidates was Visual Studio Code. I downloaded it to my machine and tested out how easy was to set up. I was skeptical, being an Electron app, of it even being a candidate. Once I launched it, it instantly recognized the Python virtual environment I had and suggested to install a sane set of extensions, which provided all the Language Server Protocol functions I had in Emacs (and some more 1), including the best Python completion I have ever seen and the easier, best debugger I encountered thanks to the launch configurations.

I was annoyed, because I did not want to like it. And however, I had a tingling feeling the first time I saw all of it. I felt again how it was to be instantly productive again. Not having a finnicky LSP configuration that requires 40 minutes of my Monday to fix, just booting a fresh install and writing code.

The problem with my Emacs configuration at some point, when it included my blog generation, mail reading and RSS feed (yes, for real, I’m not kidding) was that it had overgrown its configuration to be reliable. I currently use NixOS as my daily driver, and (surprisingly) I did not struggle to set up almost any of my tools with it. However, I never managed a convincing way to configure Emacs reliably with Nix. There were too many corner cases for me to take into account 2.

My Emacs was a very sharp knife, since I had sharpen it myself in 498 commits. And yet, the knife’s handle was not great. I love Emacs, but I realized that I enjoyed customizing it more than I actually enjoyed using it in my day-to-day.

Using VS Code had its issues but it did feel the editor was, by default and not by having 600 lines of elisp being point to its head, trying to help me. It felt really productive, and it had the sweet spot of configuration options, that could be configured in the GUI or using a text file 3. It is an Electron app and still it feels snappier than some native apps. And still, performance was never Emacs’ feature: Emacs Lisp is single threaded and, although it supports asynchronous calls, most extensions do not use it. It is hard, and it takes real Emacs knowledge to make performant elisp code. Of course, the code the average user will write to suit their own needs will most likely be single threaded. Mine was, at least.

I love Emacs. I just came to the realization that Emacs is better as a hobby, and for hobby projects. I’m not in college anymore, and I don’t plan on spending my free time hacking at a text editor to include the new party trick I just came up with. If I ever have to edit Lisp, Emacs is the clear winner. However, to get things done at work, I currently use Visual Studio Code. And it works great, to be honest.

The new blogging setup

So, after this enlightenment, I went back to the Unix philosophy: Do One Thing and Do It Well 4. And I already had a proven app for it, Hugo. Currently, the blog setup is completely decoupled from the editor, and works beautifully. Hugo is used to generate the site out of some Markdown files (that can be edited anywhere), and a quick job in GitHub Actions builds the site and deploys it to its FTP. That way, I have a Pages-like workflow without incurring in any kind of walled garden.

I have lost, however, the power of org-mode for writing the code 5. Did I ever needed the power of org-mode? Well, probably not. Definitely not for blogging. Markdown is more than enough for this.

The visual style of the site has changed as well. I loved the looks of my org-mode CSS, but the effort of adapting it was not worth it since it had its own issues and I wanted to tweak some things myself. The theme is currently my fork of a well known Hugo theme, cactus. There is plenty of work left to do in my fork, but I am happy with the results. Let me know however if you see that something is broken!

Switching from my org-mode setup to Hugo had some instant wins. The post story generation works out of the box (previously it was a list curated by hand), and some features I were never able to configure are one switch away, like the RSS feed.

Lesson learned

At work, I am always actively keeping to minimize any possible technical debt we might incur in. It was surprising when I realized how much I neglected that in my personal setup. It required some work but at least now I have the blog working again, and the gained maturity of being more flexible with the tools I use. Being able to use some other editor was unfathomable, simply because of the sunk costs I already had incurred in configuring Emacs so much. Being able to take a different perspective and try other tools was a healthy position, no doubt.

I have written this post in roughly 1h 40m, since I started writing until I ran git push. In the meantime I also had a coffee, I called my aunt and I read about Robert Lewandowski’s signing for FC Barcelona. 1h 40m, with no tweaking and no issues. Being able to do this in 1h 40m, after three years and a half being unable to post, really puts a smile in my face.


  1. Microsoft being Microsoft ships VS Code with Pylance, their own closed source LSP implementation for Python. I do not agree with the philosophy, but I have to admit is miles ahead any other option. ↩︎

  2. I’m not a Nix wizard, so that may be on me. However, it is still telling that, having moderate Nix expertise, Emacs was the only tool I could not configure. ↩︎

  3. I do know Emacs’ customize. I don’t like it. I’m sorry. ↩︎

  4. Growing up is realizing that Unix mostly ignores its own philosophy, but let’s give it a shot because it is a good idea anyway. ↩︎

  5. Just because I chose Markdown - Hugo speaks org and can generate the site out of .org files with no issues. ↩︎