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.

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

How I learned about delete-selection-mode

One thing I really like about stackoverflow.com is that you end up learning as much answering questions on there as you do by asking them.

For example, when I saw this question I was sure there would be a way to delete a region by simply starting to type after selecting the region, but I didn’t know how. However given that this is emacs, I seriously doubted the person asking the question would be the first one to want this particular feature.

Sure enough, a quick dig around EmacsWiki brought up delete-selection-mode which does exactly what the poster wanted. And I’ve learned a little bit more about Emacs, again.

At this rate I’ll be reasonably proficient in Emacs in a decade or two :).

Repost – how to get rid of those pesky ^M characters using Emacs

I had another of these annoying mixed-mode DOS/Unix text files that suffered from being edited in text editors that didn’t agree which line ending mode they should use. Unfortunately Emacs defaults to Unix text mode in this case so I had an already ugly file that wasn’t exactly prettified by random ^M characters all over the place.

I also don’t have the cygwin tools on the machine that I was seeing this problem on, I couldn’t just run unix2dos or dos2unix over the file and be done with it, but at least I had emacs on that machine. So, emacs to the rescue again…

First, I used query-replace to get rid of the ^Ms in so the file was turned into a “proper” Unix text file. The trick here is that you need to use control-Q to quote the control character. In my case on a Windows box, the key sequence was M-Shift-% Control-Q Control-M and then use the empty string as a replacement value. Job done, we’ve now got a proper Unix mode text file. Well, after almost wearing out the ‘Y’ key but of course you can use replace-string instead.

In order to turn the Unix mode text file into a Dos mode one, run the command set-buffer-file-coding-system with the parameter undecided-dos and save the resulting file. Job done.