2023-04-02
Blogging with Emacs, Org-Mode, Make and Lisp
════════════════════════════════════════════
The problem
───────────
This blog is a static web-site. For the last year I have been using
[Hugo] to build the HTML-pages, but I have become more and more
dissatisfied with the results:
*1/* The theme I developed for [Glitzersachen] with Hugo —
[Brutalist-Minimalist] — felt more and more not quite right. I am hard
pressed to pin-point exactly what bothered me. But it definitely
rubbed some of my esthetic sensibilities, and also was not quite
minimalist enough.
So this was a already motivation to develop another theme. If
everything else would have been OK, the new theme would have been a
Hugo theme again, but I also developed some issues with Hugo.
*2/* Hugo has its own templating language. Supposedly it is derived
from some standard [Go] string templating system. But in the end it is
another fringe domain specific language that makes it difficult to do
uncommon stuff in the language itself.
Generally, all those templating languages are pet peeve of mine. I
don't like them, and will soon write about what I consider the better
alternative. Spoiler: A real, general, programming language can cover
all my templating needs and allows more general processing while
expanding a template.
*3/* Hugo has its own — probably very good, but ultimately difficult
to comprehend — system to structure source and do the processing. It
is often not clear to me what has to be done that a source file (not
text, for example an image) in format /X/ arrives at the site in a
processed format /Y/.
Maybe that requires wrapping the Hugo invocation a number of
additional scripts anyway.
A [Make] based system on the other side would allow the user to add
rules and additional dependencies to the final target and employ tools
they already know well.
*4/* Generally, Hugo is not extensible. There is definitely no way to
tell it to process the argument of a macro in an external tool
(e.g. PlantUML).
My general impression is, that Hugo is not a system for Hackers. It is
a bundle of solutions for people who want to do the /usual/ thing, but
nothing that is extensible in a way that one can build a complete
authoring system on it with formats (embedded or text external) that
the Hugo authors have not though about supporting (e.g. PlantUML or
Mermaid).
The advantage, of course, is, that it is portable between Posix
systems and Windows — which most applications are not. On the other
side, this is decidedly not my use case, so I do not profit from this
portability.
I'd generally assert that the integration of Hugo into the tooling of
the system on which it runs is practically nil, so the power of that
tooling is lost to the user.
*5/* [Org-Mode] source is definitely only second class citizen with
Hugo. Unfortunately I am writing my notes almost exclusively in Org
format, so there is a certain additional effort involved in publishing
something on the blog.
Also, my indexing and notes organization relies on properties of the
Org format. If I write blog articles in a different format, they will
not be registered by the indexing.
Again, there are ways around that, yes, but why should I bother, given
that I can have a blogging system that uses Org files as first class
citizens?
[Hugo]
[Glitzersachen]
[Brutalist-Minimalist]
[Go]
[Make]
[Org-Mode]
And a solution
──────────────
My solution so far:
• Lisp is actually a very good templating language in itself. We don't
need string based templating. And above all not these strange
inheritance mechanisms from [Jinja] or [Mako].
• Make is a pretty good tool to automate the production of files from
sources. It also has the additional advantage that it is — due to
its rule based nature — easily extensible.
• Emacs can (for the moment) do the heavy lifting of parsing and
converting Org files to HTML.
So I rolled by own [static site generator] after some superficial
research if something similar to the system I envisioned was already
available (it was not).
My site generator is called Orxite (a play on the word /Org-Site/) and
will be available at [gitlab.com/m-e-leypold/orxite] some time in the
near future.
I will also blog in the near future about the ideas it tries to
implement.
[Jinja]
[Mako]
[static site generator]
[gitlab.com/m-e-leypold/orxite]
Comments
────────
Due to legal pitfalls in Europe there is no comment section in this
blog at the moment (sorry), but you can discuss this article or
comment on its content ➡ [here on Mastodon].
[here on Mastodon]