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.

A couple of useful Emacs modes

This is a repost from my old blog – I’m moving some of my older articles over as nobody knows how long the machine that hosts that blog will still be around.

highlight-changes-mode – as the name implies, it highlights changes that you make to a file. I do find it useful for the typical scenario of checking out a file, making a couple of smaller changes to it and then having to diff it to work out what you actually changed. As mentioned over at Emacswiki it doesn’t play too nicely with font-locking but I’ll try out some of the suggestions in the “Taming Highlight-Changes-Mode” section on this page. The one big advantage is that it’s available on an out-of-box GNU Emacs, so you don’t need to install any new modes.

nxml-mode – my preferred mode for editing XML. Of course it would be better if I could be bothered to create schemas for some of the files I’m editing but even without them, it does a pretty good job. As it’s trying to parse the XML that you write, it’s very helpful when it comes to highlighting mismatched tags or auto complete tags.

ido-mode – I’ve only recently started to use it and I’m still trying to work out if it is useful enough for me or if the improved file finding capability does bother me more than it helps. Yes, I know it can do a lot more but so far I’m only using the improved file finding and buffer switching. I really rate the buffer switching which is the main reason I leave it turned on.

Not really a mode, but I like using bm.el for visible bookmarks. I don’t use bookmarks that often but the package is extremely useful when I do need them.

Improving the Emacs integration in Windows

I was trying to make Windows a little more Emacs-friendly (or was it the other way around?). First step was to enable the emacs server in my .emacs so I could make use of Emacs for quick and dirty editing tasks that require an editor better than Notepad but where the average Emacs startup time was just a little too long to make Emacs a viable alternative. A typical example would be to use Emacs as the editor for commit messages in Mercurial. A quick tweak of my global .hgrc provided me with an appropriate editor setting:

           ... other settings ...
  editor = C:\Emacsen\emacs-24.1\bin\emacsclientw.exe -c

Please note that there are no quotation marks around the emacsclientw command line, adding them will result in an error message rather than an Emacs frame. Guess how I found that out. I would also suggest to extend the command line to include the “alternate editor” parameter -a to either start Emacs or another editor if there is no Emacs server running. Given that I tend to start Emacs right after I start the browser and the email client on most machines, this would be an unnecessarily cluttered command line for my use.

I also set up Emacs as an external editor from Visual Studio as described in this blog post, so now I can hit Tools/Edit in Emacs from Visual Studio 2012. Hooray! The only tweak I made to the emacsclientw invocation described in the blog post was to make “+$(CurLine)” the first parameter of the emacsclient invocation. That way, the Emacs cursor position is synchronised with the cursor position in Visual Studio at the time you invoked “Edit in Emacs”.

A(nother) tool post

I generally don’t post that much about the tools I use as they’re pretty standard fare and most of the time, your success as a programmer depends more on your skills than on your tools. Mastery of your tools will make you a better software engineer, but if you put the tools first, you end up with the cart before the horse.

I guess people have noticed that I use Emacs a lot :). My use of it is mainly for writing and editing code (and some newsgroup reading at home using Gnus) and I generally use it only for longer coding sessions. As a lot of my work is on Windows, one of the main tools I use is Visual Studio – almost exclusively 2010 right now, although I’ve taken a few peeks at 2012 and have used pretty much every version since VC++ 4. While I tend to use Emacs as soon as I’m editing more than two lines I tend to make the small changes that you get to make while debugging in Visual Studio.

I did actually try SublimeText 2 a little while back as people were raving about it in various podcasts and on blogs. I did like its speed and uncluttered appearance but quickly fell into the “old dog refusing to learn new tricks” routine. OK, this is a slight exaggeration but after a few days I didn’t get the feeling that using it over Emacs did anything to my enjoyment of programming or my productivity. I think part of the problem is that using any editor out of the box versus an editor that one has used over several years and customized   to reflect new things learned about both one’s own tool use and ideas borrowed from co-workers is simply not a fair comparison, but it is similar to a musician trying out a new instrument after getting comfortable with his current instrument over a few years. If you do care about your craft an editor is a central piece of your workflow and once you can use it without having to think about how you accomplish a certain task, it gets harder to change.

Nevertheless, I would recommend that if you are a programmer in search for a better editor than the one your IDE offers and don’t want to invest the substantial amount of time to get comfortable and productive with the editing dinosaurs like Vi/Vim and Emacs, go check out SublimeTex t2. I promise it is worth your while.

Oddly enough my main takeaway from trying out SublimeText 2 was that I – who has been proponent of high-contrast colour schemes for editors like the one used by the old Norton Editor (yellow on blue) – really got into the low-contrast default theme. So much in fact that with Emacs 24’s theme support, I’m now using this version of zenburn for Emacs. The other takeaway was that I really appreciated the fast startup time and having a slightly better editor around than Notepad when it came to all the quick editing tasks one has to accomplish that would either mess up my carefully set up Emacs or require a second instance of Emacs for “scratch editing”. I ended up with Notepad++ for that and it seems to do the job admireably so far.

Another of the tools I discovered on Scott’s Hanselman’s blog is Console2. I much prefer it over the standard Windows command prompt so give it a whirl! I also tried ConEmu as Scott recommended that in a separate post – I’m a little undecided as of yet which one I prefer, both seem to work just fine and are a massive improvement over the original MS command window – if you’re a command line junkie like I am, having one or two tabbed command windows hanging around rather than a plethora of command windows is a massive boon. Try both, see which one you prefer – so far I do like the feel of ConEmu actually being developed (there are frequent new releases available) but Console2 simply seems to work, too. I think it’s just a matter of personal preference.

Speaking of command line tools, I recently had one of these “wow, these guys are still around” moments when I discovered that JPSoft is still offering a replacement command line processor for windows. I used to be a pretty heavy user of both 4Dos and 4NT back in the early nineties when they were distributed as shareware and you had to buy the documentation as a proper dead tree version to acquire a license. Actually I think I still have both manuals in a storage unit somewhere…

Anyway, I have been playing with the latest incarnation of their free command line tool (TCC/LE) and I really like it. Enough so that I’ll probably end up buying the full version. Basically if you are looking for a “DOS prompt on steriods” rather than using Bash via Cygwin or Powershell – which aren’t always that useful, especially if you need compatibility with existing batch files – I would strongly recommend you check it out.

Why I still use a separate editor

There is a lot that modern IDEs do well, but uncluttered writing space isn’t one of them. Once you add the various views of your project, the debug window, the source control window and various other important panes you’re left with a tiny viewport into your code. The visual clutter can be disabled of course, but you’ll get it back sooner or later. When you switch back to debug mode or build mode, for example.

Read More

Using CEDET-1.0 pre7 with Emacs 23.2

It’s been mentioned in several places that GNU Emacs versions sometime after 23.1.50 do come with an integrated version of CEDET. While I think that’s a superb idea it unfortunately managed to break my setup, which relies on a common set of emacs-lisp files that I hold under version control and distribute across the machines I work on. Those machines have different versions of GNU-based Emacsen (pure GNU, Emacs/W32, Carbon Emacs etc) so I can’t rely on the default CEDET. Unfortunately when I got a new machine and put a GNU Emacs 23.2 on there, my carefully crafted (OK, I’m exaggerating) .emacs wouldn’t play ball because the built-in CEDET conflicted with the pre7 that I had already installed on that machine.

I didn’t want to have to make extensive modifications to my .emacs, but a little time spent on Google brought up a post by Marco Bardelli on the CEDET-devel mailing list with a little code snippet that removes the built-in CEDET from the load-path. After putting this into my .emacs, my -pre7 config is working again.

For those in a similar quandary, here is the snippet in all its glory:

(setq load-path
      (remove (concat "/usr/share/emacs/" 
		      (substring emacs-version 0 -2) "/lisp/cedet")