Posts tagged: emacs

Configuring GHC development environment – tips & tricks

I started working on GHC about a year ago. Since then I learned how important it is to organize my working environment to relieve me of doing common and repeatable tasks. In this post I describe some of my configuration and practices. If you prefer reading code than lengthy blog posts you can go directly to this github repo that contains my scripts and configuration.

*nix for the win

First and foremost I am using Linux on all of my machines. Debian is my distro of choice, but any *nix based system will do. That said I believe things I describe below can’t be done on Windows. Unless you’re using Cygwin. But then again if you work under Cygwin then maybe it’s time to switch to Linux instead of faking it?


One thing I quickly learned is that it is useful to have access to different versions of GHC and – if you’re working on the backend – LLVM. It is also useful to be able to install latest GHC HEAD as your system-wide GHC installation. I know there are tools designed to automate sandboxing, like hsenv, but I decided to use sandboxing method described by Edsko. This method is essentially based on setting your path to point to certain symlinks and then switching these symlinks to point to different GHC installations. Since I’ve been using this heavily I wrote a script that manages sandboxes in a neat way. When run without parameters it displays list of sandboxes in a fashion identical to git branch command. When given a sandbox name it makes that sandbox active. It can also add new and remove existing sandboxes. It is even smart enough to prevent removal of a default sandbox. Finally, I’ve set up my .bashrc file to provide auto-completion of sandbox names. Here’s how it looks in practice (click to enlarge):


Scripting for the win

This is probably obvious to anyone working under Linux: script as much as you can. If you find yourself doing something for the second or third time then this particular activity should be scripted. I know how hard it is to convince yourself to dedicate 10 or 15 minutes to write a script when you can do the task in 1 minute, but this effort will quickly pay off. I have scripts for pulling the GHC source repositories (even though I do it really seldom), resetting the GHC build tree, starting tmux sessions and a couple of other things.

Environment variables

In the beginning I wrote my scripts in an ad-hoc way with all the paths hardcoded. This turned out to be a pain when I decided to reorganize my directory structure. The moral is: define paths to commonly used directories as environment variables in your shell’s configuration file (~/.bashrc in case of bash). Once you’ve done that make your scripts dependent on that variables. This will save you a lot of work when you decide to move your directories around. I’ve also defined some assertion functions in my .bashrc file. I use them to check whether the required variables are set and if not the script fails gracefully.


Bash has a built-in auto-completion support. It allows you to get auto-completion of parameters for the commonly used commands. I have auto-completion for cabal and my sandbox management scripts. When GHC 7.8 comes out it will have support for auto-completion as well.


I use Emacs for development despite my initial scepticism. Since configuring Emacs is a nightmare I started a page on GHC wiki to gather useful tips, tricks and configurations in one place so that others can benefit from them. Whatever editor you are using make sure that you take as much advantage of its features as possible.


GHC wiki describes how to set up Firefox to quickly find tickets by number. Use that to your benefit.


Geoffrey Mainland managed to convince me to use make and I thank him for that. Makefiles are a great help if you’re debugging GHC and need to repeatedly recompile a test case and possibly analyse some Core or Cmm dumps. Writing the first Makefile is probably the biggest pain but later you can reuse it as a template. See here for some example Makefiles I used for debugging.


The goal of this post was to convince you that spending time on configuring and scripting your GHC development environment is an investment. It will return and it will allow you to focus on important things that really require your attention. Remember that most of my configuration and scripts described in this post is available on github.

Configuring Emacs is a nightmare

When I started using Emacs a few months ago I went through some effort to configure it to my liking. There were a couple of issues I wasn’t able to resolve back then. I decided that it’s time to get them fixed. That’s how I wasted two days doing something that should take no longer than an hour.

About 90% of my time went to configuring Emacs running under Tmux. While Emacs runs fine under terminal emulator (I’m using Konsole for that) it turned out that running it under Tmux causes numerous problems: some key combinations don’t work and even worse the colours get screwed up. I am using Tmux always when working in console and at first I wanted to blame Tmux for all the problems. Soon I realized that all other applications work correct and only Emacs is causing problems. Problems with key combinations were solved using xterm-extras add-on. I am not exactly sure what is causing issues with colours but this is related to TERM environment variable. Within Tmux this is set to screen, while my terminal emulator sets it to xterm. If I understand correctly Tmux takes care of translating between these two different modes, but it looks that Emacs is still affected by this difference. Of course I tried changing values of TERM in all possible ways, but things only got worse. I tried improving Emacs’ colours by using color-theme but under my terminal emulator this breaks completely. I enabled 256 colours (by default there’s only 8!), but still I mostly got garbage when applying different themes. Oh well, I can live with 8 colours just fine. This was day one.

On the next day, when things were more or less working fine, I decided to upgrade Emacs to version 24.2. I was tempted by Emacs’ built in package management system and a promise of better compatibility with terminal emulators. This was a mistake. I spent another day trying to figure out why configuration that worked fine under 23.2 breaks under 24.2.

I acknowledge the fact that if I had arcane knowledge of Elisp all my issues would be much easier to solve. Without that knowledge I have to resort to googling and voodoo programming. Well, I am just an ordinary user who just wants to use a text editor. I need a text-based editor so I can do almost all of my work using console. Emacs meets that requirement, which makes me more productive but I seriously doubt that this increase in productivity justifies time needed to configure editor to my needs. I guess I would be proud of myself had I managed to solve all the problems. I didn’t and there are still unresolved issues:

  • How can I manage keyboard shortcuts in a sane way? I install some expansion only to realize it is not working because keyboard shortcuts collide with the ones from different expansion. I can remap the keys, but then again I run into risk of colliding with other shortcuts.
  • Can I have a block mode in Emacs similar to one offered by Kate (under KDE)? I found that rect-mark allows me to mark a rectangle area and cut it, but pasting doesn’t work the way it should.
  • Emacs’ undo is clumsy. I managed to improve it by using undo-tree, but still it has rough edges: every delete is seen as a single operation. If I hold backspace and delete 30 characters Emacs sees that as 30 separate operations! Undoing that is a real pain.

Solving these issues would make Emacs a very decent editor to work with Haskell (though not as good as Eclipse is for Java). Perhaps one day I’ll find patience and energy to resolve the remaining problems. Until then I steel myself for using Emacs the way it is.

Haskell IDEs, Part 4: Emacs revisited and Summary

In the previous parts of this post I reviewed three different development environments for Haskell: Emacs, EclipseFP and Leksah. This is the last part in which I plan to write about Emacs once again and then summarize all the reviews.

My main problem with Emacs was inconvenience when working with multiple files, mostly because I found switching between buffers (i.e. opened files) annoying. After posting the review there were comments that recommended extensions that could solve these problems.  Here’s the list of extensions that, after some testing, I decided to use:

  • IDO mode. IDO stands for Interactively Do Things and it greatly improves file opening and switching between buffers. When opening a file it shows the list of files and directories in a current directory, allows to navigate the directory tree in an easy manner, provides intuitive filtering capabilities and allows to select a file easily by selecting its name using arrow keys. Similar behaviour is provided when switching between opened buffers. A nice introductory tutorial to IDO can be found here.
  • NumberedWindows improves switching between multiple windows by pressing the Meta key and a number of a window1. This is much easier to type then C-x o.
  • CycleBuffer allows switching to next/previous buffer using F9/F10 keys. That’s an alternative to IDO-enhanced C-x b command.

These three extensions are a huge win. They greatly improve overall Emacs experience. There’s plenty of other window- and buffer-enhancing extensions that I haven’t mentioned – you can take a look at them on Emacs Wiki here and here.

Right now I’m missing two things in Emacs: a bit tighter integration with GHC/GHCi and a possibility to browse through the source tree. First problem should theoretically not be a problem, since haskell-mode and ghc-mod both offer good integration features but, as I mentioned in my review, some of these features didn’t work as the should or at all. I hope this could be resolved with a small effort. As for the source tree browsing, there are of course extensions. One of them is ECB, but I haven’t tried it yet.


This series was meant to give you a rough idea of what three Haskell IDEs – Emacs, EclipseFP and Leksah – have to offer.  As you’ve seen I was enthusiastic about EclipseFP and Emacs, but very critical about Leksah. I would however suggest not to rely solely on my opinion and test each of these environments on your own. I’ve seen people on #haskell praising Leksah, so perhaps that project is not a lost cause (as my post could have suggested). I also made one omission – vim. There are Haskell modes for vim as well, but I’ve never been proficient in it so when I was faced with improving my vim skills or learning Emacs from scratch, I chose the latter (I think the key factor was the fact that I was learning Scheme at the same time). As a general thought, I have to say that there is no Haskell IDE that would boost my efficiency as a programmer the way Eclipse boosted my Java programming efficiency. I don’t know if such IDE will ever be created, but it would be nice to have at least any kind of refactoring capabilities. At the moment none of the IDEs has such and the programmer has to manually perform repetitious tasks like renaming variables. I’m definitely waiting for this to improve.

  1. Don’t get confused by Emacs’ terminology. A window in Emacs is an area that displays the context of the buffer within a frame. You can split editing area horizontally or vertically and each of these areas is called a window. Term frame is equivalent to what is normally referred to as a window in modern GUIs []

Staypressed theme by Themocracy