The author’s blogging pipeline begins with Org-mode documents that serve as the single source of truth, containing prose, executable code blocks, d2 diagrams, and bibliographic references. By staying inside Emacs, the author avoids context switching and maintains a consistent writing environment where all computations supporting the content can be evaluated in place. This design reflects an evolution of earlier Emacs‑centric attempts, now refined to keep the publishing side smaller, typed, and easier to understand while preserving Emacs as the central hub for creation.
When it is time to publish, a Gleam‑based converter processes each Org file: it invokes Pandoc to convert Org to GitHub Flavored Markdown with citation processing, applies three custom Lua filters for verse preservation, bibliography grouping, and path translation, then passes the result to Blogatto to generate the final HTML structure. Simultaneously, Gleam and Lustre work together to produce type‑checked HTML elements for the site layout, ensuring that generated pages are structurally sound. The author illustrates this with a Gleam function that takes a list of posts and returns a Lustre element for the post index page, showing how the entire pipeline benefits from static type checking throughout.
This image illustrates the conversion pipeline described in the second paragraph, where Org files are processed by Pandoc and Lua filters before Blogatto generates HTML.
Nix flakes and devenv provide a reproducible development environment that pins exact versions of Gleam, Pandoc, make, and other dependencies, allowing the author to enter a fully configured shell with a simple ‘nix develop’ command. This reproducibility eliminates reliance on globally installed tools and guarantees that the same build environment can be recreated on any machine, supporting the author’s goal of a pleasant, predictable workflow inside Emacs.
The author argues that Org-mode is superior to Markdown for this use case precisely because it remains interactive within the editor—features like source code blocks, diagrams, and citations can be manipulated and validated in real time rather than requiring a separate build step to see results. While Org‑Publish could automate much of the pipeline, the author found it difficult to achieve desired quality‑of‑life features such as syntax highlighting when generating HTML, reinforcing the decision to keep conversion steps explicit and separate.