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

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.

I finally started using ELPA

My normal development workflow doesn’t use that many different Emacs packages. With a few exceptions I’ve mainly worked with a “stock” Emacs distribution and augmented that with a few select Emacs packages that I downloaded manually. It worked for me for a decade or so, and it made it reasonable easy to move configurations between machines – zip & copy was my friend for that, although I’ve since changed that to using dropbox.

As we recently switched to git at work, I started looking into Emacs git clients and came across magit. At that point I figured a pre-built package would be nice and started looking into ELPA. I use Emacs 24 pretty much wherever I have an Emacs install so having ELPA in place everywhere came in really handy.

Didn’t take very long for me to switch away from the manual package “management” to get the few minor modes and other helper messages via ELPA. I don’t think I’ll go back to manual management.

Guess I should check if the weblogger package – which I am using to write this blog post – is also available in one of the repositories.

So if you’re still using manual package management, I would recommend looking at ELPA together with the marmalade repository. The default ELPA repo didn’t include several of the packages I needed, but combining ELPA and marmalade covered everything I’ve needed so far.

With Emacs on Windows, make sure you know where your $HOME is

The Gnu Emacs for Windows distribution appears to be pretty good at inferring where a reasonable place for $HOME is, straight out of the box. In my case, said reasonable place was %USERPROFILE%/AppData/Roaming which was an entirely acceptable default.

That is, until several other tools entered the picture and disagreed with Emacs. We’ve recently switched to using git at work and the git ecosystem  needed to have some ideas where its home was. I’m using Git Extensions as the “regular” Windows GUI and TortoiseGit for the Windows Explorer integration, plus the awesome Posh-Git that even made me learn basic PowerShell.

All of this worked fine until I threw magit into the mix. I like being able to interact with the VCS directly from Emacs (who doesn’t?) and magit is probably the greatest VCS integration for Emacs. It worked fine as long as I kept the cheat sheet handy, but a colleague of mine pointed out that my magit commits supposedly came from a really funky user that looked very much like the computer guessed my email address rather than the user configured in my git configuration.

Turns out that both git and Emacs respect and look at the HOME environment variable. After settling on a suitable location and adjusting %HOME%, I moved the various dot files into the correct location and can now commit correctly from Emacs with the correct user details. Phew.

Oh, and for those commits that did have the odd username on them, the following commands came in really handy.

To change the author on the current (well, last) commit:

git commit --amend --author="corrected author"

Or if you just want to update the author on the last commit after updating HOME to point at the correct location:

git commit --amend --reset-author