Moving this blog to a static site – this time I’m serious (because org-mode)

I have been toying with the idea of migrating this blog to a static site to simplify its maintenance for some time. While WordPress is a great tool, this blog is a side project and any time I have to spend maintaining WordPress gets deducted from the time I have to write for the blog. Keep in mind that I’m self-hosting this blog and it’s actually running on a Linux VM that only handles the blog. That is yet another server that I need to administer, and it’s the odd one out, too, as all of the others are FreeBSD or OpenBSD servers.

Oh, and one of the big advantages of using a static site generator is that the whole site can be put in version control, archived there and also quickly re-generated from there should I manage to spectacularly mess up the host. A WordPress restore is a fair amount more work, as I found out about two years ago.

The only parts that don’t back up that well are the comments, especially if I use a self-hosted system for them.

Migration is fine, but what to?

For that reason, I had experimented with moving the blog to Jekyll for quite a while. In fact, I have maintained a parallel Jekyll blog for years now. For a smooth switch over, the devil was in the details though, and I was never happy enough to actually migrate and shutdown the WordPress site.

After another patchapalooza, I revisited the idea of converting the blog to a static site and looked at several other static site generators. I also decided to resurrect an experiment I had started with Hugo. My first attempt hadn’t been very successful, so I stuck with Jekyll. This second attempt however is a lot more successful as it addressed a couple of the issues that kept me from being happy with Jekyll:

  • Hugo builds the site much faster than Jekyll
  • I found a theme that I’m really happy with.
  • It looks like some of the details that I found hard to get right in Jekyll are already handled nicely in Hugo. This is mostly around the RSS feed generation – Hugo by default generates category feeds in addition to the regular “full” feed. It also looks like the category feeds are very similar path-wise to what WordPress uses, so hopefully the RSS feeds should continue working with the couple of aggregators that picked up this blog.

Fortunately, this time I succeeded in importing the site from Jekyll into Hugo. It took some work to clean up some of the artifacts that originated in the WP-to-Jekyll conversion, and then I had to convert the Liquid template code to Hugo shortcodes. The latter was pretty easy, but a bit tedious. Just not tedious enough to write a script to do it.

Hugo can render org-mode files (and so can Jekyll, apparently)

Another nice feature is that my workflow can still use org-mode for when I want to use it to write longer posts. Shorter posts I usually crank out in Markdown, but for the more complex posts it’s nice to have org-mode as an option. Especially if the post contains source code.

While the setup I described before with using org-mode to post to WordPress is mostly working, it’s a bit clunky especially if you’re using more than one computer to work on blog posts. Both Jekyll and Hugo can handle org-mode files directly – in fact, even though this file would be as effortless to write as Markdown, what you are currently reading is actually a processed org-mode file. Assuming that you’re reading this on the static site, that is.

What’s left to before the actual cutover?

There are two fairly large items I have to tick off the todo list before I can cut over for good.

  • Migrate the comments. Now this blog doesn’t get a ton of comments, but I appreciate all of them and am trying to migrate them over to this blog. As I believe in self-hosting everything, I’m experimenting with isso, and I need to redo some of the experiments with Hugo as so far, they’ve been completely focussed on Jekyll. Hugo does have built in support for disqus, plus this theme has support for staticman, but neither of the two are my preferred alternatives.
  • QA the site, especially the RSS feeds so that they hopefully keep working as they do right now.
  • There are still some minor tweaks to be done, analytics integrated and all that, but those are probably going to happen slowly after the cutover.
  • Oh, and the last item is all of the draft posts that have accumulated on WordPress that I somehow never got around to finishing.

The beta of the static site is here if you want to have a look. Any feedback is welcome.

[HOWTO] Installing Emacs 26.3 on Ubuntu or XUbuntu 19.04

My previous instructions for installing a newer Emacs version on Ubuntu still work. Ubuntu (and in my case, XUbuntu) 19.04 ships with Emacs 26.1 out of the box. As usual I want to run the latest version – Emacs 26.3 – as I run that on my other Linux, FreeBSD and macOS machines.

I only had to make one small change compared to the older instructions. Instead of running the versioned sudo apt-get build-dep emacs25 I rand sudo apt-get build-dep emacs. Once the dependencies are installed, you’re a configure/make/make install away from having a working Emacs 26.3:


timo@timos-thinkpad:~/Downloads/emacs-26.3$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 19.04
Release:	19.04
Codename:	disco
timo@timos-thinkpad:~/Downloads/emacs-26.3$ $HOME/local/bin/emacs --version
GNU Emacs 26.3
Copyright (C) 2019 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Some of the other instructions on the web mention that there is now a PPA for the latest stable Emacs versions. I’ve not personally used it as I’m comfortable with building Emacs from the command line. The other advantage with building Emacs from scratch is that it coexists with any other version that you installed from the Ubuntu repositories or other PPAs. This way you can avoid problems like the one described in this askubuntu Stackexchange discussion.

Wrapping up the Emacs on Mac OS X saga

In a previous post I mentioned that I upgraded my homebrew install of Emacs after Emacs 26.2 was released, and noticed that I had lost its GUI functionality. That’s a pretty serious restriction for me as I usually end up with multiple frames across my desktop. I did end up installing the homebrew Emacs for Mac tap which restored the GUI functionality. It had have one niggling problem for me, though. My muscle memory says that I use Shift-Meta-7 (aka Meta-/ ) for keyword expansion as I use a German keyboard layout most of the time. Unfortunately, with Meta mapped to the Apple Command key, Shift-Meta-7 is a menu shortcut. Instead of expanding keywords, I kept opening menus. That clearly wouldn’t do.

Malcolm Purvis had been kind enough to point out in a comment to my original homebrew Emacs post that Davide Restivo had created a brew tap that brings the necessary –with-cocoa build option back. He just upgraded it to Emacs 26.2, so this morning I rebuild my Emacs on OSX again and ended up where I wanted to be, with the latest version of Emacs, keyword expansion as I expected it to work, and a working GUI. Thanks, Davide!

And yes, it might come across as silly to rebuilding the editor just to get my preferred key combination back. It probably is – after all, I could’ve just remapped the key combination in my .emacs. I tend to run Emacs across a myriad of platforms (Linux, OSX, Windows, FreeBSD to just list a few) and having a “stock” Emacs experience on all of these platforms means that my .emacs has only a minimal amount of OS-based conditionals in it. For example, it has the following OS X specific combo:

;; On OS X/Darwin, make sure we add the path to the homebrew installs
(when (string-equal system-type "darwin")
  (setq exec-path (append exec-path '("/usr/local/bin")))
  (global-set-key [home] 'move-beginning-of-line)
  (global-set-key [end] 'move-end-of-line))

In fact, the above block is the only OS-specific configuration in my whole .emacs file. I’d like to keep it that way.

Emacs 26.2 on WSL with working X-Windows UI

I’ve blogged about building Emacs 26 on WSL before. The text mode version of my WSL build always worked for me out of the box, but the last time I tried running an X-Windows version, I ran into rendering issues.  Those rendering issues unfortunately made the GUI version of Emacs unusable on WSL. Nothing like missing the bottom third of your buffer to cramp your style. Or your editing.

Going all in with Emacs 26.2 with Cairo

I’ve just built the newly released Emacs 26.2 on my Ubuntu WSL with the options –with-cairo –with-x-toolkit=gtk and it looks like the rendering has improved massively. I’ve also recently upgraded VcXsrv to version 1.20.1.1, so it’s not quite clear to me if this is due to improved compatibility of WSL itself, changes between Emacs 26.1 and 26.2, or the fact that I turned on Cairo or VcXSrv upgrade.

Screenshot of a freshly built Emacs 26.2 running on WSL
Emacs 26.2 with Cairo on WSL

I’m still seeing a couple of odd rendering issues that I can’t fully reproduce. They’re mostly around the resizing and buffer splitting, which I can live with for now. The Cairo renderer is known to still have a few bugs, so that might be contributing to the problems I’m seeing. I’m just happy that I do have a 95% working Emacs on WSL.

One other oddity I noticed is that I have to specify -d to set the display if I want to enable the GUI. Setting DISPLAY in the environment doesn’t quite seem to do the trick for now. I will keep playing with this a little more to see if I’m overlooking the blindingly obvious.

There’s also a little issue with Emacs not being able to connect to VcXsrv if I just specify -d localhost:0.0. This should work but the only way I can get it to work is by using -d 127.0.0.1:0.0. I suspect that’s because I recently added IPV6 capabilities to my home network and for some reason, VcXsrv doesn’t listen on the IPV6 interface. And no, -d ::1:0.0 doesn’t work, either.

Anyway, here we have another self-referential screenshot of the Emacs UI showing me working on this blog post:

Working on this blog post, still with Cairo turned on
Working on this blog post, still with Cairo turned on

Here we go again, this time without Cairo

I ended up rebuilding the Emacs binary without Cairo support as the rendering issues got a little annoying. Disabling Cairo seems to have taken care of the rendering issues during buffer splits for now. I’ll still have to look into the IPV6 issue at some point, but for now I’m pretty happy with the final result. So for our final, final result for today, here’s a non-Cairo screenshot running the anti-zenburn theme with powerline with its default theme.

Emacs, no Cairo, anti-zenburn with powerline
Emacs, no Cairo, anti-zenburn with powerline

Enjoy!

And now, an Emacs with a working org2blog installation again

I mentioned in my previous post that I somehow had ended up with a non-working org2blog installation. My suspicion is that this was triggered by my pinning of the htmlize package to the “wrong” repo. I had it pinned to marmalade rather than melpa-stable, and marmalade had an old version of htmlize (1.39, from memory). The fact that marmalade is erroring out with an expired certificate is most likely a sign that I need to stop using it. Anyway, re-pinning htmlize to melpa-stable unclogged that particular problem and the updated org2blog flowed onto my machine.

As a bonus, I ended up following the instructions for installing org2blog v1.1.0. While that version is not yet available on melpa-stable, it exposed me to use-package, which is something I’ve been meaning to look at but haven’t got around to so far. A quick glance at the docs – which is all I’ve had time for so far – suggests that I really need to look at use-package in depth and possibly update my .emacs to make use of it rather than continuing to maintain the home grown package installation wrapper I’ve been using for the last few years.

Either way, I’m happy to be able to blog from Emacs again rather than having to suffer WordPress’s built-in editor.

Unwelcome surprise – homebrew Emacs has no GUI after OS X Mojave update

I finally got around to upgrading my OS X installation from Mojave to High Sierra – my OS update schedule is usually based on the old pilot wisdom of “don’t fly the A model of anything”. As part of the upgrade, I ended up reinstalling all homebrew packages including Emacs to make sure I was all up to date. That proved to be a big mistake as I suddenly had a GUI-less Emacs. Of course I found the post on Irreal about the Emacs homebrew package being broken on Mojave after, well, I noticed that my Emacs GUI wasn’t working. Oops.

A bit more poking around the Internet brought me to the homebrew cask for the Emacs Mac Port. As the screenshot below shows, it works with a UI on Mojave, so if you’re looking for an alternative to the regular Emacs port, this one seems to be fine, at least based on a quick “test drive”.

Screenshot of a GUI Emacs 26.1.92 running on Mac OS X Mojave
Working Emacs For Mac on OS X Mojave

Time to make sure that the installed packages are also working as it doesn’t seem to recognise org2blog and I ended up having to write this post in the WordPress editor. Can’t have that.

Emacs 26.1 has been released (and it’s already on Homebrew)

Saw the announcement on on the GNU Emacs mailing list this morning. Much to my surprise, it’s also already available on homebrew. So my Mac is now sporting a new fetching version of Emacs as well :). I’ve been running the release candidate on several Linux machines already and was very happy with it, so upgrading my OS X install was pretty much a no brainer.

Here we go:

Screenshot of Emacs 26.1 running on OS X
Emacs 26.1 on OS X, installed via homebrew

Another way to use Emacs to convert DOS/Unix line endings

I’ve previously blogged about using Emacs to convert line endings and use it as an alternative to the dos2unix/unix2dos tools. Using set-buffer-file-coding-system works well and has been my go-to conversion method.

That said, there is another way to do the same conversion by using M-x recode-region. As the name implies, recode-region works on a region. As a result, it offers better control over where the line ending conversion is applied. This is extremely useful if you’re dealing with a file with mixed line endings.

Mixed line endings due to version control misconfiguration are actually the main reason for me having to use these type of tools in the first place…

Emacs 26.1-RC1 on the Windows Subsystem for Linux

As posted in a few places, Emacs 26.1-RC1 has been released. Following up my previous experiments with running Emacs on the Windows Subsystem for Linux, I naturally had to see how the latest version would work out. For that, I built the RC1 on an up-to-date Ubuntu WSL. I actually built it twice – once with the GTK+ toolkit, once with the Lucid toolkit. More on that later.

The good news is that the text mode version works right out of the box, the same way it worked the last time. I only gave it a quick spin, but so far it looks like it Just Works.

Read More