Install your basic Emacs packages via a single function call

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.

As I started using ELPA last year, I decided to investigate if I could use ELPA and a little custom code to download and install the packages that I know I want everywhere. One evening I got bored enough to write a function that tests for the presence of a bunch of basic packages that I want to have on every Emacs install. It’s not trying to be fancy and automate things to the n-th degree as I didn’t want to spend the time each time I start Emacs, so I just have to remember to invoke the function after a new install. Here is the function, in all its simple glory:

(defun install-required-packages ()
  (if (>= emacs-major-version 24)
      (progn
        (setq package-archives '(("ELPA" . "http://tromey.com/elpa/")
                                 ("gnu" . "http://elpa.gnu.org/packages/")
                                 ("marmalade" . "http://marmalade-repo.org/packages/")
                                 ("melpa" . "http://melpa.milkbox.net/packages/")
                                 ))
        (package-refresh-contents)

        (when (not (require 'bm nil t))
          (package-install 'bm))
        (when (not (require 'icicles nil t))
          (package-install 'icicles))
        (when (not (require 'smex nil t))
          (package-install 'smex))
        (when (not (require 'zenburn-theme nil t))
          (package-install 'zenburn-theme))
        )))

Unique buffer names in Emacs

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:

(require 'uniquify)
(setq uniquify-buffer-name-style 'post-forward uniquify-separator ":")

The above code will display duplicate buffers as “one.py:left” and “one.py:right”, with “left” and “right” being the directories that contain the file. The screenshot below shows Emacs with two files with the same name opened from two different locations:

Screen Shot 2014-08-23 at 3.49.46 PM

Sprinkler controller upgrade part III – setting it up

Putting the OpenSprinkler and Raspberry Pi together was easy, getting them to run showed my inexperience when it comes to playing with hardware. The overall install went pretty smoothly and the documentation is good and easy to follow so I’m not going to ramble on about it for very long, but just throw up some notes.

First, my old card reader didn’t want to play with any of my computers. Now, the card reader is ancient, but should have been able to work with an SD card. No joy under and available OK, so I ended up having to get a new SD/microSD only card reader.

When writing the ospi image file to the SD card using Mac OS, make sure you write to the raw device and not to the slice (in my case /dev/rdisk4 and not /dev/disk4s1), otherwise you’ll end up with a non-booting OSPI and wonder why. Don’t ask me how I know

Also, the OSPI image doesn’t have Emacs pre-installed, so I obviously had to fix that. I mean, how would I be editing configuration files otherwise?

The hardware installation (aka screwing the controller to the wall and wiring it up) was pretty simple, to facilitate the install I had taken photos of the way the old controller was wired and use that as a guide.

The whole install went pretty smoothly and the controller has been running our sprinklers for a while now. Unfortunately the sprinkler_pi program that I really wanted to use to seems to have encountered a bug that has it trigger multiple valves at the same time; I’m planning to upgrade to the latest version and if necessary debug it a bit because I like its UI better than the default interval_program. The latter however just worked out of the box.

The only concern so far is that the CPU temperature on the Raspberry Pi seems a little high (it’s usually hovering around 60-65° Celcius as it’s outside in the garage. I might have to experiment with a CPU heat sink on that one.

Running Emacs from a Windows Explorer context menu

It’s one of those days, thanks to a hard disk going south I ended up having to rebuild the system drive on one of my machines. After putting the important software back on there – “Outlook and Emacs”, as one of my colleagues calls it – I had to reapply some of the usual tweaks that make a generic developer workstation my developer workstation.

One of the changes I wanted to make was to have an “Edit in Emacs” type context menu in Windows Explorer. The only reason I was keeping another editor around was because it’s a feature I use regularly but hadn’t got around to setting up for Emacs.

StackOverflow to the rescue, as usual. I used the registry script provided in the first answer and tweaked it slightly. In contrast to a lot of people, I don’t keep Emacs running all the time but only when I’m editing something. For that reason like my Emacs setups to either start a new instance if there is no Emacs running or use an existing instance as a server if there happens to be one running.

With my little tweaks to start an instance of Emacs even if there is no Emacs server running, this is what the updated registry script looks like:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT*shell]
[HKEY_CLASSES_ROOT*shellopenwemacs]
@="&Edit with Emacs"
[HKEY_CLASSES_ROOT*shellopenwemacscommand]
@="C:\Tools\emacs\bin\emacsclientw.exe -a C:\Tools\emacs\bin\runemacs.exe -n "%1""
[HKEY_CLASSES_ROOTDirectoryshellopenwemacs]
@="Edit &with Emacs"
[HKEY_CLASSES_ROOTDirectoryshellopenwemacscommand]
@="C:\Tools\emacs\bin\emacsclientw.exe -a C:\Tools\emacs\bin\runemacs.exe -n "%1""

There’s another neat little tweak in there, too – the directory “C:toolsemacs is actually a symbolic link to the current installed version of Emacs on this machine so whenever I update my version of Emacs, I don’t have to redo other scripts and settings that try to use the current version of Emacs.

This might be an old hat to most Unixheads, but it’s slightly unusual on Windows so I figured I’ll mention that it’s possible to do something like this on Windows also.

Make GNU Emacs play nicely with a German keyboard layout on Mac OS X

I used to use Carbon Emacs on OS X for quite a while, but with the release of Emacs 24 I switched to the stock GNU Emacs distribution. While GNU Emacs works fine on OS X, once you throw a German keyboard layout in the mix it doesn’t work so well as OS X uses Option + Number keys for a variety of characters needed for programming like [] and {}. GNU Emacs uses Option as Meta out of the box so the key mapping doesn’t work overly well, especially if you do a lot of programming in the C family of languages.

I finally got fed up with this restriction as it seriously affected my enjoyment of cranking out code under OS X. A bit of duckduckgo’ing gave me the necessary settings to use Command as Meta and pass Option through to the underlying OS. From my slightly hazy memory, this was the default layout for Carbon Emacs.

Here’s the code that will switch the keys around:

(setq mac-command-modifier 'meta
      mac-option-modifier 'none
      default-input-method "MacOSX")

Yes, there is also the whole argument about the unsuitability of using a German keyboard layout for programming. A lot of German programmers I know switched to UK or US layout keyboards to make programming easier.

I can drive one of those keyboards if need be but I’m both a touch typist and I rely on Kinesis Advantage keyboards for my day-to-day work thanks to an injury from a less than ergonomic desk quite a few years back. While this old dog is generally happy to learn a new trick or three, I draw the line at switching keyboard layouts when there are other options available.

I seem to be getting addicted to icicle-mode

Not that I’m doing much with it yet other than the more minibuffer completion, but I really notice when icicles is not installed or inactive, so I’ve ended up adding it to every Emacs installation I use. ELPA is coming in really handy as it’s a matter of just installing icicles via one of its repos rather than having to install it manually. I’m really going off manual installs of complex Emacs packages these days after doing it for so long.

One thing I really appreciate about icicles is that it subtly extends Emacs in such a way that you don’t notice its presence, but even after a couple of days I very much notice its absence. Of course its presence in the menus is much more obvious and pronounced, but I rarely use Emacs menus, preferring to drive it via the keyboard shortcuts. I’ll be experimenting with icicles a bit more because this mode has all the makings of a must have mode, at least for my setup.

And of course it’s another distraction from learning eshell. Oh well.

Anyway, check out icicles if you haven’t done so already.

Getting emacs’ansi-term to play nicely with FreeBSD

I was playing with the various shell options – sorry, trying to learn eshell – this evening. While playing with eshell I learned about the second, fully fledged terminal emulator ansi-term.

Most of my machines here run FreeBSD, as does the machine that hosts this blog. FreeBSD’s terminal emulators don’t recognise eterm-color as a valid terminal type, plus FreeBSD uses termcap and not terminfo, so the supplied terminfo file was of limited use.

As usual, StackOverflow came to the rescue with this answer. After adding the termcap entry and rebuilding termcap.db, ansi-term is now recognized as a full featured terminal emulator, running inside emacs. So now I can do this:

Screen Shot 2014-01-07 at 10.09.17 PMThat’s midnight commander running on one of my FreeBSD servers, inside GNU Emacs on my Mac. Job done.

And yes, ESC-0 is passed through correctly so I can actually exit mc.