Irreal

Every Irreal reader who’s paying even a little attention knows that this site is WordPress based. It’s been that way since 2011, and I’m pretty satisfied with it as a blogging platform. Still, it would be nice to have a bit more control and not have to suffer the occasional WordPress vagary.

The thing is, most of the static site solutions involve something like Hugo, which, as far as I know, is an excellent piece of software but is just another thing that I don’t have control over and doubtless comes with its own set of problems.

James Dyer is a Hugo user but, like me, would like to have a process that is completely Emacs centric. Therefore, he has been running an experiment in using Org-publish as the basis of his blog publishing workflow without depending on any external software. Right now, he’s considering this a backup to his Hugo-based system and his workflow includes importing the posts from the Hugo workflow to the Org-publish one. If the experiment is a success, he will be able to replace his Hugo workflow to one that is entirely Emacs based.

If you’re interested in having a static blog site, take a look at Dyer’s post for some good ideas for a starting point. Emacs really can handle the whole process as Dyer shows.

Anyone who’s been reading Irreal for a while knows that I’m a huge fan of Mu/Mu4e for dealing with my email. It has just the right features for my preferred workflow. That includes it’s robust search capabilities that allow me to store all my emails in a single repository and find them easily. That saves me a lot of time and mental cycles trying to decide where to store saved emails: they all go to the same place.

Another thing I like about mu4e is that it’s text based. Who, after all, wants their emails running arbitrary Javascript? Most people apparently. The majority of the email I get that’s not from fellow nerds is HTML based and often includes some sort of Javascript. I hate this but I deal with it very successfully by using the built-in view-in-xwidget command so that I can read HTML emails as they were composed (complete with the Javascript).

Hong Xu has a nice post that shows us how to move in the other direction. Mu4e will try—with various degrees of success—to display HTML by default but it doesn’t use XWidgets and the results are often less than optimal. Xu’s post describes how to make mu4e switch between HTML and plain text display for those occasions when the HTML display is distracting.

The change is simply the setting of a keymap entry for the mu4e-view-mode-map so it’s easy to add to your configuration without a lot of bother. Xu’s change along with compiling in the XWidget support gives you fine control over the way an email is displayed.

I’m not much of an IDE fan but many (most?) people are and want, in particular, to have some LSP integration for their favorite language. Lots of folks are using Python these days either as a quick-and-dirty scripting language or as their main programming language.

If your personal Venn diagram intersects with those two sets as well as the Emacs users set, The Emacs Cat has a useful post that describes his configuration for an Emacs-based Python IDE. It seems like a nice setup but doubtless some people will carp that there are better Pythons IDEs outside of the Emacs sphere.

Such a claim begs the question, “What do you mean by better?” It probably means that the LSP-like functions are better, that it can complete your partial library function better, or something similar. The thing is, you won’t be in Emacs and you won’t have all the unexcelled Emacs editing capabilities. Those are, to me, much more important than function completions and the like.

Still, it’s possible to have both and The Emacs Cat shows you how to do that. For whatever reason, Python has always been difficult in Emacs so it’s nice to see a post that gives a usable configuration for it. I’ve written about this before but that was almost 9 years ago before Eglot and Tree-Sitter were part of Emacs. The Cat’s post brings us up to date with what’s available now.

It’s Christmas, a day that we at the Irreal Bunker celebrate in large part by being slothful. Therefore, today’s offering is a quickie. On the other hand, since it is Christmas, you can also think of this post as a Christmas gift.

Over at the Emacs subreddit, ArcanistCheshire tells us that building Emacs with the Lucid toolkit resulted in an impressive Emacs speedup. This is seconded by Karthink, someone who has shown he knows what he’s talking about.

Sadly, if you’re a macOS user this gift is not for you. It’s only for users of X-windows and even then there are some restrictions. Take a look at the post for the details.

Even if you are a macOS Emacs user, you can take heart because being an Emacs user is a gift all by itself. Merry Christmas

A constant theme here at Irreal is that one of Emacs’ virtues is its programmability. Not the ersatz programmability offered by VS Code or even Vim but real programmability. You can introduce new code or change old code while Emacs is running in a seamless manner.

But why is that so important? Aren’t knobs and check boxes enough? Positron has a nice video that provides the answer. The TL;DR is that, no, knobs and check boxes are not enough. They’re more complex to implement and maintain, they quickly go out of date, and they simply aren’t as flexible. With programmability, the user is in charge and can evolve the action of Emacs as needs change.

Positron makes a good point about Elisp and its supposed slowness. The code you write for Emacs happens, as Positron puts it, at the other end of the keyboard and therefore at human speed. It doesn’t matter if it’s slower than C or whatever. It’s fast enough for human senses. For those jobs that require more powerful computation, Emacs simply subcontracts them out to an external process for faster processing.

As far as I know, only Lisp Machines and their descendants offer this kind of programmability. Today, the only widely used piece of software that can do this is Emacs. To me it seems not so much an advantage as a necessity.

It’s a short video (4 minutes, 35 seconds) so take a look. Positron makes some good points.

Marie K. Ekeberg has a holiday gift for Emacs users: a list of 24 Emacs packages that you can try during the holidays. The list is interesting in that it doesn’t really have a theme other than that they’re packages that Ekeberg finds useful or interesting. Some of them are builtin, some of them are in MELPA / Gnu Elpa, and some of them aren’t in any ELPA repository.

Some like Org-mode, Windmove, Magit, EXWM, Multiple cursors, and vterm will be familiar to most Emacs users but some may be new—at least they are to me. The first on the list is Try. Mike Zamansky often used it in his Emacs videos to try out a package without actually installing it. If you want to sample some of the offerings from the list, installing Try first is a good idea because it lets you experiment with a package without having to commit to it.

Another very useful package is undo-tree. It’s a little hard to get used to but it really will improve those times when you have to undo some text. It also rationalizes “redo”. That alone is worth installing it for.

One package that I haven’t tried but that looks interesting is focus. The idea is that text outside some configurable region get grayed out. I’m not sure it would work for me but it does look interesting. It provides a perfect example of why you should install Try: you can experiment with it and if you don’t like what you see, it will disappear the next time you start Emacs.

The list is worth taking a look at You may find something that will fit in with your workflow.