Building Emacs on OS X using homebrew

I’ve recently switched to using Homebrew as my source for Emacs on OS X  after seeing this blog post by Philip Ingram.

It’s a simple way to install a current Emacs once or twice a year. I don’t use beta versions or other pre-release versions on “productivity” machines, only released versions. My editor is too important a tool for me to risk using pre-release versions.

Scheduling WordPress posts with org2blog

Another metablogging post, but this may come in handy for people who like to produce blog posts in bulk and schedule them for publication in WordPress at a later date.

In my case, my ability to find time to blog is directly correlated to my workload in my day job. That’s why you see regular gaps in my posting that may last for a few weeks to a month or two.

To counteract this, I try to write multiple blog posts in one sitting when I’ve got both the time and am inspired to write, then schedule them such that WordPress pushes them out automatically over the next few days or weeks. My normal workflow for this was:

  • Write post in org2blog
  • Publish post to WordPress, adjust the publication date
  • Edit the post in org2blog again, push in and then remember to tweak the publication date because org2blog overwrote the publication date

The last two steps of course are unnecessary. See the #+DATE: line in the first line of the screenshot?

org2blog highlighted date entry
Date section in an org2blog post during editing

When you create a new blog post using org2blog/wp-new-entry, just edit the date that org2blog automatically inserts to your desired post schedule and the setting will carry over into WordPress. Easy if you know how.

TLS issues with Emacs and Git for Windows

I’ve recently blogged about adding TLS support to Emacs 24.5 on Windows and improving git performance on Windows by installing an alternative git command line client. The reason I ended up investigating how to add SSL and TLS support to Emacs is that when I originally upgraded from the official git Windows client to the Git for Windows build, I ended up with non-working TLS support in Emacs.

The TLS issues only occur if you tell the git installer to add git and all supporting Unix utilities to the path, which is not the default setting for a git installation on Windows.

However if you do install git with this setting, Emacs ends up finding the openssl libraries on the path. This works fine with the older versions packaged with the installer from git-scm.com but results in TLS issues with SSL/TLS connections failing with the newer binaries shipped with Git for Windows. I didn’t dig deeper into why I was seeing the issue as I was in a hurry to get Emacs working again, so I looked for the quickest way to resolve it.

tl;dr – if you’re running into TLS issues with Emacs on Windows and just installed Git for Windows, follow the instructions in Adding TLS Support to Emacs 24.5 on Windows to get SSL/TLS connection from inside Emacs working again.

Adding TLS support to Emacs 24.5 on Windows

The Windows build of Emacs 24.5 doesn’t ship with SSL and TLS support out of the box. Normally that’s not that much of a problem until you are trying to access marmalade-repo or have org2blog talk to your own blog via SSL/TLS.

Adding SSL and TLS support to the Windows builds of Emacs is easy. SSL/TLS support in the official Emacs build for Windows isn’t enabled because it doesn’t ship with the necessary support libraries, but you can get pre-built binaries from the ezwinports project on Sourceforge. Installation is simple – grab the desired binaries (I used gnutls, but there’s also an older openssl build available) and extract them into the root directory of your Emacs install. The directory layout is the same and mimics the standard Unix directory layout so everything ends up in the correct place.

After the next restart of Emacs, a quick

M-: (gnutls-available-p)

should result in ‘t’, showing you that Emacs has found the gnutls binaries. All of a sudden, org2blog can talk to my blog again and I’m finally set up the same way I am on the other OSs I use.

ezwinports has a whole bunch of other useful libraries available as well, like libpng, so check it out.

One caveat – the ezwinports libraries are 32 bit libraries so they work fine with the official 32 bit build of Emacs for Windows, but you need to look into alternatives if you use a 64 bit build.

Improved syntax highlighting with org2blog and custom CSS

As mentioned in an earlier post, I changed my blogging workflow to org2blog for writing and editing posts in Emacs and only push them up to my WordPress blog when the posts are almost done. I still do the final editing in WordPress so I can tweak the SEO settings and all that, but the majority of the work happens in org-mode now.

One area that really needed improving was the appearance of the source code that I put in posts. Before I started using org-mode for blogging I edited the code in Emacs, ran it through htmlize and pasted it into my blog post.. That way the Emacs theme I’m using also determined what the generated HTML looked like and it allowed me to control the code’s appearance to a certain extent. Once I moved to org-mode, I just got a generic htmlize output.

In order to improve the appearance output, I switched from the inline styled export to CSS-based export. That way, I can tweak the CSS for the basic syntax highlighting, pick appropriate background colours and all that fun stuff.

First, prepare WordPress for additional custom CSS

The web is full of warnings that you shouldn’t edit your installed WordPress theme so you don’t lose all your customisations the next time the theme is updated. The usual recommendation is to create a child theme instead. This does exactly what I needed to, but felt awfully heavyweight for the comparatively simple task at hand. All I wanted was jam some additional CSS onto a page and be done with it.

I’m using Jetpack on my self-hosted WordPress install for certain additional features that you’d normally only get when hosting a blog on WordPress.com. Jetpack has a neat feature called “Custom CSS” that allows you to add additional CSS to your existing theme’s stylesheets. In other words, it allows you to provide exactly the kind of customisation I need to tweak the source code highlighting. If you haven’t activated the Custom CSS feature yet, go to your Jetpack settings and activate it.

Adding org-mode’s code export CSS

This is a relatively simple operation. First, you need to tell org-mode to export the source code formatting information using css and not the more usual inline style. This is easily done by adding the following setting to your .emacs and re-evaluate that particular piece of code:

(setq org-export-htmlize-output-type 'css)

Once that’s done, the easiest way to get the parts of the CSS that are relevant to source code formatting is to create an org file, stick a #+BEGIN_SRC/#+END_SRC block in there and export that to HTML. You can then pull the relevant parts of CSS out of the resulting HTML buffer and put it into the custom CSS settings provided by Jetpack.

In my case, the relevant CSS looks like this:

pre {
  border: 1px solid #ccc;
  box-shadow: 3px 3px 3px #eee;
  padding: 8pt;
  font-family: monospace;
  overflow: auto;
  margin: 1.2em;
  -moz-border-radius: 5px;
  border-radius: 5px;
}
pre.src {
  position: relative;
  overflow: visible;
  padding-top: 1.2em;
  background-color: DarkSlateGrey;
  color: WhiteSmoke;    
}
pre.src:before {
  display: none;
  position: absolute;
  background-color: white;
  top: -10px;
  right: 10px;
  padding: 3px;
  border: 1px solid black;
}
pre.src:hover:before { display: inline;}
pre.src-sh:before    { content: 'sh'; }
pre.src-bash:before  { content: 'sh'; }
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
pre.src-R:before     { content: 'R'; }
pre.src-perl:before  { content: 'Perl'; }
pre.src-java:before  { content: 'Java'; }
pre.src-sql:before   { content: 'SQL'; }
pre.src-clojure:before { content: 'Clojure'; }

Copy your customized CSS into Jetpack’s “Custom CSS” edit control, save your changes and you’re done. The next time you publish a post from org-mode using org2blog, it’ll automatically apply the above CSS to all your code blocks that were marked as such.

GNU Emacs 24.5 on (X)ubuntu 14.10

GNU Emacs 24.5 was released on April 10th. I’m in the process of setting up a dual boot Windows/Linux machine right now as I’m slowly moving away from Mac OS X, mainly because of the cost of the hardware but also because I don’t like it that much as a Unix-y development environment anymore.

Xubuntu 14.10 only comes with Emacs 24.3 and it looks like 15.04 will “only” include 24.4 so now is a good time as any to manually install 24.5. Please note this is not a complaint about Ubuntu and its many contributors. They do a great job, I’d rather have a stable system comprised of well-tested packages and install the exciting, cutting edge stuff manually.

A manual “out of the box” install is actually pretty easy. I followed the instructions for installing 24.4 on UbuntuHandbook, substituting 24.5 where appropriate. I also installed Emacs in a user-local directory tree as I really don’t like mixing system-wide tools that have been installed by the package manager and manually installed packages in the same directory tree. Yes, I’m weird like this.

All in all the install was completely hassle free and allows me to send a test blog post from Emacs 24.5 on my new Xubuntu box to the blog using org2blog as usual.

Update: The instructions linked to above also work for Ubuntu 15.04 – you have to rebuild your Emacs 24.5 for 15.04 as some of the dependencies have changed.

Setting up Emacs spell checking on OS X

As I mentioned in yesterday’s post, I’m trying to improve my blogging workflow by using org2blog to draft my posts before pushing them to my WordPress blog. When I posted yesterday I had the basic workflow going, could edit posts in Emacs, save them, update drafts and push them to WordPress. The last piece that was missing was getting spell checking to work.

I’ve actually never spent much time thinking about spell checkers until I discovered that OS X doesn’t come with a spell checker that ispell recognises. A little research led me to Joel Kuiper’s blog post on spell checking in Emacs on Mac OS X. I decided to install Hunspell as it seemed to be modern, supported and able to do the job. Plus, it’s available via Homebrew which I’m already using to install other Unix software on my OS X machine. A quick

brew install hunspell

followed by me grabbing the German and English dictionaries from OpenOffice.org and I was in the spelling business. Just make sure that you unzip the .oxt files containing the dictionaries, copy/move the .dic and .aff files into either ~/Library/Spelling or /Library/Spelling (I prefer the first one) and run hunspell -D to check that it’s picking up the files. Oh, and don’t forget to set up soft links from default.dic and default.aff to your default language’s dictionary files.

Now I should be able run M-x flyspell-mode and we’re in business, correct? Only we weren’t, because my Emacs setup couldn’t find hunspell. Oops. Turns out I had neglected to add the Homebrew installation directory to the exec-path, with predictable results. The following code in my .emacs fixes that:

;; 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"))))

With the above in place and Emacs being able to find the hunspell executable, it was time to add the following code to my .emacs to ensure that ispell and flyspell use hunspell if it’s available:

(when (executable-find "hunspell")
  (setq-default ispell-program-name "hunspell")
  (setq ispell-really-hunspell t))

Now flyspell-mode is happily running using Hunspell at it’s time to crack open an adult beverage.

Improving my blogging workflow using Emacs (of course)

I try not to post too many metablogging posts. Other people do it better and I’m trying to focus on journalling what I learn as a software engineer and manager, not what tools I use for blogging. However after losing another post to WordPress’s built-in editor I decided Something Must Be Done. I think this is only the second post I lost, but it’s a fairly regular occurrence for a journalist friend of mine and I really don’t have that much time to retype blog entries that ended up in Bit Nirvana.

My first attempt was to resurrect the weblogger-mode setup I used to have a while ago but after switching the admin interface on my WordPress install to https, I couldn’t quite get it to work again. Plus it was a bit of a half hearted attempt as I never quite warmed to this mode in the first place. It’s actually quite odd as I tend to use gnus semi-regularly and the interface is very similar, but it never quite clicked for me for writing blog posts.

If I would exclusively blog on Windows, I’d just use Windows Live Writer, but as I switch between Windows, OS X, Linux and FreeBSD depending on which machine I’m on, Windows only software just isn’t going to cut it.

As everybody raves about org-mode (which I admittedly have never used) I decided to give org2blog a chance. It’s probably not the smartest idea to try to learn too many new tools at the same time but at least Emacs doesn’t occasionally eat my scribblings. Plus, I’ve started using Jekyll for another one of my experimental blogs, so using org mode and having they ability to publish to a Jekyll blog is also very useful.

So far I’ve got the basics up and running and the main blog configured. I’m using visual-line-mode to do automatic line wrapping and now will have to set up flyspell on the machines that haven’t got it installed yet so I can have basic spell checking.

So far, the basic workflow I’m planning is:

  • Sketch the post(s) and write the drafts in Emacs in the comforts of my local machine
  • Publish them as drafts to my standalone WordPress install
  • Do the final editing and spill chucking in WordPress
  • Ignore or heed the recommendations from the WordPress SEO plugin. That’ll be mostly ignore, then
  • Schedule the final publishing on the WordPress admin console

Hopefully that should work better than the “log into WordPress and start typing” approach I’ve used so far.