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.

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

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.

Yes, I promise I’ll shut up about Emacs package management via ELPA any minute now.

Based on the feedback I had on my last post about using a combination of melpa and melpa-stable, I looked into using pinned packages via the package-pinned-packages variable that’s new in Emacs 24.4’s package.el. I couldn’t find any simple examples on how to use it, but a quick look at the source code and some playing around in ielm got me there. Well, after I finally upgraded to Emacs 24.4 on my main machine.

I’ve blogged about a little elisp snippet I use to install my preferred base set of Emacs packages before. Thanks for all the feedback, it definitely helped improve the code.

One issue that kept annoying me is that there is no simple way to tell ELPA to mainly pull packages from melpa-stable and only fall back to melpa for those packages I can’t get on melpa-stable yet. I decided to extend my code to handle that situation with some manual inputs as I know which packages can’t be found on melpa-stable. It proved surprisingly easy to do so after mulling over the problem a little.

I’ve been using the official GNU distribution of Emacs for Windows for the last few years and am very happy with it. Well, usually I am very happy with it until someone sends me a 25GB log file I need to analyse and the 32 bit Emacs refuses to play when faced with the enormity of the file in question.

This happened again recently so I finally decided to go look for a 64 bit Emacs for Windows, which led me to emacs-w64:

MELPA has recently got its own domain (melpa.org) so it’s time to update your list of package repositories with the new URL.

Speaking of MELPA, I recently switched to their stable repository instead of their “regular” nightly build/snapshot repository after I accidentally ended up with a cider build that didn’t want to playing ball. This is not a complaint - if you use nightly builds etc you know what you’re getting yourself into - but it prompted me to switch over to using the stable package repository instead on those machines that I consider production machines. This of course require me to uninstall and reinstall a bunch of packages but that only took a few minutes.

For those who aren’t aware of this yet, there is an Emacs Stackexchange site that’s currently in beta. I’d like to encourage everybody to take part in it so it can become a viable site on the Stack Exchange network.

If you, like me tend to carry around or “cloud around” a single .emacs file so you end up with similar environments wherever you have an Emacs install, you know it’s a little painful to ensure that you have the same set of basic packages installed on each one of your Emacs installations. As I had mentioned before I don’t use that many third party packages so my Emacs configurations aren’t that complicated, but I always prefer to have the computer remember things so I don’t have to.

A common annoyance with Emacs when working on a code base that has duplicate file names is that the mode line tends to display the buffer names as “one.py:<1>”, “one.py:<2>” etc etc. That doesn’t help much with telling them apart and I find it confusing.

I was introduced to the Uniquify library a while ago. This library allows you some control over how you want to display the buffer names of buffers that contain files with duplicate names. I use the following configuration in my .emacs: