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:

  [ui]
           ... 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")
	      load-path))

A couple of useful Emacs modes

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.

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.

My Emacs configuration file refactor

In a previous post I described that a few months ago, I moved the third party elisp code under version control to make it easier to move it between machines and ensure a consistent configuration across them. The one remaining problem to solve was putting the configuration files (.emacs and .gnus.el) under version control. One of the approaches I really liked was described by Nathaniel Flath but I figured that it was too heavyweight for my needs.

What I ended up doing was to move the configuration files into version control and then simply change the basic dot-files to load the file from the subdirectory that is under version control. My .emacs now reads like this:


(load-file "~/emacs-lisp/dot-emacs.el")

Not the most elegant and automated version but it works for me.