Recent Articles

Emacs Muse meets Common Lisp

This blog of mine is written in the very good
Emacs Muse format, that I find
much more friendly to writing articles than both
org-mode and
markdown-mode
that I both use in a regular basis too. The main think that I like in Muse
that those two others lack is the support for displaying images inline.

Here's what it looks like to edit with Emacs Muse

The Muse publishing system

The idea is that you edit
.muse files in Emacs then use a command to
publish
your file to some format like HTML. You can also publish a whole project,
and then enjoy a fully static website that you can deploy on some URL.

The drawback of using the Muse format here is to do with the associated
tooling. I didn't take time to study Muse Emacs Lisp sources and probably I
should have, as I found myself the need to add support for
tags and per-tag
rss support. What I did then was using Muse provided
hooks so that my code
gets run here and there.

With my additions, though, publishing a single article took a painful time,
something around 30 seconds for the main page of it and then about as much
(sometimes more) to publish the project: previous and next articles
sections, tag files, rss files.

from Emacs Lisp to Common LIsp

and Common Lisp is different from Emacs Lisp

When I realized that my motivation to writing new blog articles was going so
low that I wasn't doing that anymore, I raised the priority of fixing my
blog setup enough so that I would actually do something about it. And then
decided it would actually be a good excuse for another
Common Lisp project.

I've been using
esrap to write a Muse parser along with
5am to test it
extensively. It turned out not an easy project to just parse the articles,
but thanks to
cl-who (that stands for
with-html-output) the output of the
parser is a very simple
nested list data structure.

In the
Emacs Lisp Muse system there was a cool idea that you could embed
(compile time) dynamic sections of
<lisp>(code)</lisp> in the templates, so
I've kept that idea and implemented a
Server Side Include facility.

The idea has then been to build a dynamic website without any level of
caching at all so that anytime you reload a page its muse source file is
parsed and intermediate representation is produced. Then the
SSI kicks with
adding the
header and
footer around the main article's body, and replacing
any embedded code calls with their results. Finally,
with-html-output-to-string is used to return an HTML string to the browser.

With all that work happening at run-time, one would think that the
performances of the resulting solution would be awful. Well in fact not at
all, as you can see:

So it takes about
80 ms to render a full dynamic page. That's way better
than what I wanted to achieve!

the static compiler

That said, we're talking about the ability to render about
12 pages per
second, which is not something acceptable as-is for production use. And
given the expected ratio of reads and writes, there's no good reason to
publish a dynamic website, so the next step here is to build a
static
website compiler.

So it takes about 20 seconds to publish again the whole website. The reason
why it's ok for me not to optimize this yet is because I've also been
changing the CSS and HTML parts of the website, and each time the header or
the parser is changed, or even some SSI function's output, then I need to
compile the whole set of files anyway.

The displaying-time macro

While building this little Common Lisp project, I've added to my still very
little toolbelt a macro that I like. Here's how to use it: