Category Archives: Unity

Compiling Unity projects from within Emacs

I’m often asked how I get Emacs to compile up Unity projects*, and I thought it would be worthwhile writing a proper post on what I’ve done to make this a relatively painless process.

Once you’ve followed this post you should get syntax highlighting, in-Emacs compiles and on-the-fly syntax checking, as well as autocompletion and refactoring. I should say that this *doesn’t* stop Unity re-compiling your files when you switch back to it – I’ve not made any attempt to unify them, as I suspect it’s more trouble than it’s worth.

The key elements are:
– A ‘make’ script.
– Flycheck
– CSharp-mode.el
– Omnisharp-emacs

The make script

My make script is something I hacked together in python a couple of years ago, worked out from examining the compile commands Monodevelop emits, and it has grown to support various features. You can download it from here – be warned it’s not particularly pretty, and flits between about 3 different coding standards…

Drop it into the root of your Unity project and change it so it captures your source files. The arguments the make script expects are ‘fast/slow’ (explained in a moment), the working directory of the compile (usually the root of the Unity project) and, optionally, a file to exclude and a file to add (again, explained below).

The ‘fast/slow’ bit is something I added to allow for faster compiles. Once you’ve got a Unity project that includes lots of generic game libraries (your own utility functions, NGui, etc) compile times can slow down quite a bit. It therefore makes sense to partition your code into ‘stuff that’s rarely changed’ and ‘actual game stuff’, and only compile the rarely changed stuff… well, rarely.

If you look at the code of the make file there’s one function to get the source files for the rarely change library, and another function to get the source for the main game. If you pass down the ‘fast’ option, it the make script won’t bother compiling the library; if you pass down ‘slow’ it will. In this way it’s possible to keep your general compile times down in Unity to a couple of seconds, even for large projects.

Triggering a compile from within Emacs is fairly straightforward.

(defun unity-compile-game ()
(let ((cmd (concat "python " (project:project-root project:active-project) " fast " (project:project-root project:active-project))))
(compile cmd)))

(defun unity-recompile-game ()
(let ((cmd (concat “python ” (project:project-root project:active-project) “ slow ” (project:project-root project:active-project))))
(compile cmd)))

As you can see, all it does is create a command line of ‘python my-project-root/ my-project-root slow’ (or ‘fast’) and passes that down to the built in ‘compile’ command. I’ve got a custom project system I use in Emacs (I should probably move over to using something like projectile in the future) which I use to find the project root from a given source file – you should switch in whatever system you’re using instead.


I use the excellent flycheck to check my builds as I work. Because we’re able to keep our compile times nice and short it provides very fast feedback on code issues as you type, which I personally find invaluable. And, unlike alternatives like Monodevelop’s built in live ‘syntax checking’, it runs an actual build of the game so it’s always completely accurate.

Setting it up is fairly simple:
(require 'flycheck)
(flycheck-define-checker csharp-unity
"Custom checker for Unity projects"
:modes (csharp-mode)
:command ("python" (eval (concat (project:active-project-root) "")) "fast" (eval (project:active-project-root)) source-original source)
:error-patterns((warning line-start (file-name) "(" line (zero-or-more not-newline) "): " (message) line-end)
(error line-start (file-name) "(" line (zero-or-more not-newline) "): " (message) line-end)))

Again, switch in whatever you need to get the root of your project. Flycheck works by saving out a temporary version of the file being edited, which can then be switched for the original file in the build – this is what the ‘exclude’ and ‘extra’ parameters of the make script are for. Thus the command line looks something “python SomeFolder/ SomeFolder SomeSourceFile.cs SomeSourceFileFlycheck.cs”.

I should add that the error patterns I’ve given to flycheck are probably monodevelop specific and have only been tested on my OSX machines.


CSharp-mode provides C# syntax highlighting and other things for Emacs. It looks like it has been abandoned, but it’s complete enough that I’ve not hit any major issues with it.

I tend turn off csharp-mode’s (dodgy) imenu support and turn on it’s brace matching:

(setq csharp-want-imenu nil)
(local-set-key (kbd "{") 'csharp-insert-open-brace)

Omnisharp for Emacs
Completing the picture is Omnisharp for Emacs, which I’ve blogged about before. It’s awesome, and gives you auto-completion, refactoring and all sorts of other loveliness. I personally use it in tandem with company-mode.

Oh, one more thing. Get annoyed on OSX because double clicking a file in Unity doesn’t open it at the right line number in Emacs? Some smart chap worked out how OSX handles line numbers (the command line isn’t good enough for some operating systems, apparently) and wrote Sublime Proxy to intercept the appropriate events. I’ve (badly) hacked it to work with Emacs. Get it here and make it less bad if you want.

That’s it for now. I hope someone finds it useful, let me know if something doesn’t work.


* Okay, not really that often.


My new +3 helm of swooping

I’ve been working on a post about game design. I’ve recently (re)learned lots of fun things about game prototyping, the importance of identifying and maintaining a game’s design ‘promise’, and how critical it is to keep the design/implementation/feedback loop tight. In short, it’s a post that’s not about Emacs.

This is not that post.

I’ve recently discovered helm-swoop. Helm-swoop is an Emacs helm extension that displays a list of matches for a search term in a popup helm buffer. You can navigate the list of matches with the cursor keys, and point will jump around in the buffer being searched to the relevant line. You can also continue typing to narrow down the search term further.

I’ve nabbed a gif from helm-swoop’s github page to make it clearer:


I’ve always been quite satisfied with the various incremental searching systems in Emacs; i-search and evil-mode’s vim-style search are excellent, best-in-class systems. But I love the way that helm-swoop shows you all the matches to your search, with some context, without you having to move point. You start typing, look to see if you get the hit you want, change your mind, retype. Once you’ve got something close to what you want you move down the list of hits, keeping your eye on the main buffer, and hit enter when you’re there. It’s very slick.

On top of this, you can live-edit the helm-swoop buffer, in a manner reminiscent of Emacs 24’s occur-edit-mode. Search for ‘color’, C-c C-e to go into edit mode, change the occurrences you care about to ‘colour’, C-c C-s, and the original buffer gets your changes and proper spelling. Fantastically powerful stuff.

i-search and the evil-equivalent still have their place, of course, and I use them regularly, but I’m using helm-swoop more and more.

That’s it! Try out helm-swoop, and I promise my next post will be something a bit less Emacsy.

Somehow I managed to make that sound like a threat…

C# autocompletion in Emacs

Just a quickie. The family are in Cornwall, so I was going to take the opportunity to knock up some kind of C# autocompletion – intellisense is the only thing I miss from my days of working with Visual Studio (though it’s not enough to make me want to embrace the horrors of Monodevelop). I was intending on glueing SublimeText’s CompleteSharp binary into Emacs with a bit of elisp and unicorn dust when I noticed on Reddit that someone had created Omnisharp, which integrates NRefactory, the code analysis and completion backend for Monodevelop, into Vim. Rather splendidly, they’d implemented it via an frontend-agnostic http server, allowing other editors to call to use it.

When I originally checked there were integrations for Vim and SublimeText, so I started working out how to wrangle http POST requests in lisp, but by the end of the week I noticed that someone had beaten me to it and created the rather wonderful Omnisharp-Emacs. Fortune was on my side.

I’ve put in a bit of work integrating it with my preferred completion system, company-mode, and now the full glory of C# completion is mine. Couple of screenies:

autocompletion popup

Here you can see the popup menu with the relevant completions, and more detailed information in the minibuffer.
autocompletion parameters

And here we’ve selected a candidate and company-mode is allowing us to fill in the parameters by tabbing through them and typing in text.

The company-mode integration is sitting in a fork in github, and I’m hoping to get it pulled upstream soon.

Omnisharp has lots of other tricks too, such as showing help documentation, renaming variables, jumping to definitions and lots of other fun stuff. I’m probably going to be using this on a daily basis.

There is a minor downside to all this, which is that NRefactory works in terms of Mono/Visual Studio solution files and their associated project files, and I’ve moved my workflow entirely over to my own, Emacsy, concept of projects which doesn’t require manual registration of files and things like that. I don’t like having to add files manually, but nor do I like having two systems to maintain, so I’m going to have to work out a way of getting them to play nicely together.

Besides that, very minor, wrinkle, I’m a happy man, and I’m hugely grateful to the authors of Omnisharp, Omnisharp-Emacs and company-mode – all three are fantastic.

Which leaves the rest of the weekend free to decide whether to buy an Ergodox keyboard with Cherry Blues or Cherry Browns, and then I can wear my geek badge with pride.


After a busy weekend of github-based collaboration, company-mode is now properly integrated into omnisharp-emacs. Head on over to the github page to have a look at the awesome features we’ve piled in – return type information, documentation buffers, tabbing through method parameters, smart completion detection, it’s all there.