UberLogger – Redux

Having not touched  UberLogger for a while, two users contacted me this week with some very decent feature requests (thanks Steve and Gavin!). What should have been a fairly quick set of changes turned into an extensive rewrite. But good news – version 2 is now live!

The core of the work was around  Unity’s GUI ‘layout’ system which takes care of placing GUI widgets. Instead of specifying positions for controls, you express your layout in terms of ‘vertical’ and ‘horizontal’ sections and flexible spacers and let Unity do the work of translating that into pixel positions.

Unfortunately I hit the point where it became more trouble than it was worth. Specifically:

• I wanted to add ‘auto scroll’ to the logging list, so the logging window will automatically move to the end of the list. In order to do this you need to know where the end of the scroll window is… and when you use layouts you don’t know where the controls will end up. I tried working things out by myself, but ultimately just ended up fighting with the layouting.
• Internally, when doing the layouting, Unity calls OnGui multiple times, first to get the control positions and then to render; in order for this to work it needs the results to be consistent between runs. This is normally fine, but I wanted to optimise the log view list, which gets slow when you’re adding 10k elements to it every time OnGui is run. The obvious optimisation is to not add elements that you know are outside of the scroll view (by calculating the positions of elements by hand) but this confused the layouting system – things were different between runs, and Unity complained.

Laying things out by hand is more work, obviously, but wasn’t actually as much trouble as I was expecting, and doing so allowed me to remove some fairly hacky bits of code and make the rendering several orders of magnitude faster.

After that, there was a fight with GUI skinning; as Gavin pointed out, UberLogger didn’t work nicely with the dark ‘Pro’ skin. Unity’s internal GUI skinning system is nice and flexible, but when you’re writing an add-on that’s meant to fit in seamlessly with the existing editor GUI skin you don’t want to create a new skin, you need to harvest what’s already being used. ‘EditorStyles’ is your friend here, and contains all sorts of useful styles you can reuse (like ‘toolbarButton’, for instance).

Unfortunately, it doesn’t contain all the styles the editor uses, and the console ‘log line’ styling is notably absent. UberLogger originally bodged around this by grabbing a slider bar control and hand-modifying some of the textures and colours – which is why it didn’t work on the Pro skin.

After poking around a bit, I realised that you can find all the GUI styles by iterating over GUI.skin.customStyles; spitting out the names, I spotted ‘CN EntryBackEven’ and ‘CN EntryBackOdd’, and harvested their organs for my own logger styles.

Finally, an old and somewhat poor design decision came back and bit me. When I started writing UberLogger I initially had difficulty extracting all the information I needed from log calls made via Unity’s own Debug.Logxxx methods – in particular, you don’t get a useful callstack from them. My initial approach to fixing this was to spoof the Debug namespace with my own static Debug class and thus capture all calls to Debug.Logxxx. This works, but:

1. Doesn’t fix the problem with extracting callstacks from errors fired deep from within the bowels of Unity itself. This was fixed a while ago by wrangling the log message Unity gives to you.
2. You have to spoof *everything* in the Debug namespace, even stuff you don’t care about. This is messy and guaranteed to break if ever Unity add something to the namespace.
3. You can’t spoof everything – as Steve pointed out, among other things Debug.isDebugBuild is a property, and you can’t have properties in static classes in C#. Unfortunately this was breaking the Unity Test Tools, which is a bad thing.

Thankfully, since 1. was fixed ages ago, the proxying wasn’t needed anyway. So I’ve now moved all UberLogger debug commands from Debug to UberDebug, and renamed them from ULogxxx to just Logxxx. Obviously this is a breaking change, but I think it’s a legitimate one.

So – version two features!

• Much, much faster rendering when there are lots of elements in the log window.
• Pro skin supported.
• No longer conflicts with Unity Test Tools.
• A new ‘Collapse’ button – works like Unity’s collapse button, but grouping similar messages together.
• A new ‘Follow’ button, which makes the log window scroll to follow new messages.

As ever, you can get UberLogger from here.

Let me know if it works for you, or if you have any problems!

UberAudio – an improved audio workflow for Unity

A few months ago I decided to rewrite/tidy-up and open-source a bunch of Unity add-ons I’ve written and regularly use. First up was UberLogger, a drop-in replacement for Unity’s debug console. Next up is something slightly bigger – UberAudio.

Much like UberLogger, UberAudio is designed to take something in Unity that’s good and make it better. Unity’s built-in audio system is very powerful, but I found the workflow fell a little short of my needs; but, as ever, the marvellous thing about Unity is that it’s so easy to extend. Specific areas of audio workflow that I wanted to improve include:

• Keeping AudioSource settings out of scenes and prefabs. If the settings of an AudioSource aren’t correct, you shouldn’t have to hunt around for it and check out a scene or a prefab. All your audio should be in one place, and not in a scene.
• Similarly, if you want an audio designer to do a pass on the audio in your game, they should be able to do so without touching levels, prefabs or code. They should be able to drop new audio into the game by themselves.
• Loading. You should be able to load up audio data without having to load a new scene. UI audio, audio variations, dropping audio for things you aren’t using to save memory, even swapping out audio sets entirely – you should have control over what’s loaded and when, without changing any game logic.
• Flexible audio triggering. It should be trivial to play a random sound from a selection. Similarly, if you’ve got a variety of different creature types and they share some sounds and not others, it should be easy to create defaults and override the ones you need, without touching code, scenes or prefabs.
• Lifetime management. If a creature is playing some audio when it dies, most of the time you don’t want the audio to die immediately with it; it should finish playing first. Likewise, if you have something that plays a looping sound (a buzzing bee, for example) and it dies, the loop should be released and then end naturally. This should be the default behaviour.

UberAudio solves all of these problems, and several others, and does so without getting in your way – you can always get a handle on your raw AudioSources if you need to. It’s based on the audio systems I wrote for Dungeon Keeper and Fable, so the core design has been tested in fairly intensive production environments and historically has scaled well.

The workflow is very simple:

• Create an audio bank.
• Add audio to your bank.
• Mount the audio bank in your scene.
• In code, trigger audio ‘events’ on GameObjects. These events have an intelligent lookup system (see the readme) so you can easily create default sounds and specialise them later on in your audio banks.

Editing audio banks in Unity looks like this:

As you can see, you have exactly the same level of control over how your audio behaves as with normal AudioSources but it’s all grouped together, with some extra fields for the new functionality.

Obviously this isn’t a competitor for great tools like wWise, but if you’re looking for something simple, flexible and free, UberAudio might be what you want.

Take a look and let me know if you find it useful. Feature requests, bug reports and pull requests are always welcome!

Simon

UberLogger – a replacement Unity console and logging framework

I’ve been using Unity for a few years now and have developed a deep and unhealthy love for it. As a game development framework it’s easily the most expressive and flexible system I’ve ever used, in 20 years of making games.

However, as with most things, there’s the odd bit of friction that could be smoothed over, and one of the joys of Unity is that it allows you to address them when you want to. I’ve developed a couple of such things over the years, which I intend on releasing freely to the community.

First up is a replacement logging system for Unity. Unity’s built-in logging system and console are great – being able to click on logs to select game objects, viewing callstacks, etc are incredibly handy features. But I found myself wanting more. Specifically:

• Debug channels. When you’re trying to ship a game debug messages can get very spammy, and make it difficult to sift out the signal from the noise; at the same time those spammy messages can often be useful for tracking down rare bugs. Debug channels allow you to categorise your messages as ‘loading timings’, ‘weapon debugging’, etc, and limit your view to a particular channel, allowing you to keep all your messages without being overwhelmed by them.
• Filtering out stack frames from the callstack. It’s not uncommon to want to create your own debug layer to manipulate your logging before it hits Unity. Unfortunately, by default your new methods appear in the callstack, and the source of the error is shown to be your own debug method, which is annoying – you want some way to remove elements from the callstack.
• Inline source view. You see a bug and you want to quickly see the source code around one part of the stack frame, without necessarily jumping into your text editor.
• A modular system to allow different backends to process logs. I want to be able to write my own file logger, or my own in-game console, and have full access to the callstack, etc.
• Timestamps! I want to see when a log happened.
• A more compressed view; Unity’s console uses space somewhat inefficiently, using two lines of text for every log.
• An in-game console. Sure, much of the time I’m working in the Unity editor, but sometimes I want to see my messages on my target device.

UberLogger addresses all of these issues and some more. It’s a drop-in replacement for the default logging framework, so no code changes are needed – Debug.Log, etc, all just work, though if you want to use features like channels there are some new methods.

In the editor it looks like this:

And in game it looks like this:

It uses an MIT license, so if you’ve got any features to add send me a message (or a pull request). And if you find it useful, let me know!

Simon

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 ()
(interactive)
(let ((cmd (concat "python " (project:project-root project:active-project) "make.py fast " (project:project-root project:active-project))))
(compile cmd)))

(defun unity-recompile-game ()
(interactive)
(let ((cmd (concat “python ” (project:project-root project:active-project) “make.py 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/make.py 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.

FlyCheck

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) "make.py")) "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/make.py 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

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.

Simon

* Okay, not really that often.

‘var’, ELDoc and Omnisharp

A couple of weeks ago in the office we were having a conversation about the pros and cons of using ‘var’ in C#. If you’re not aware of it, ‘var’ is the C# equivalent of ‘auto’ in C++11; it tells the compiler work out the type of a variable declaration for you, based on the type of its initialising value. So for example:

List<GameObject> someList = new List<GameObject>();


can be replaced with:

var someList = new List<GameObject>();


The compiler can automatically work out that someList should be a list of GameObjects based on the initial assignment. Moreover because it does so at compile-time, there’s no runtime overhead, unlike with ‘real’ dynamic typing. Over time this can save a fair amount of typing, and reduces silly typo-based compiler errors.

It’s also a useful tool when refactoring. Consider the following:

foreach(SomeType loopVar in ImportantList)
{...}


This can be replaced with with:

foreach(var loopVar in ImportantList)
{...}


Now, if you change the type of ImportantList, the loop will ‘just work’ (as long as the loop body still contains valid code, obviously).

The concern in our office was regarding code readability. The more you use ‘var’, the harder it can be to work out what’s going on. For example:

var inventory = GetInventory();
var slot = inventory.GetSlot();
foreach(var item in slot.GetItems())
{ ... }


If you’re new to this code it’s hard to know what slot or item is without jumping to another file. Although I’m personally happy with the tradeoff, the concern is a valid one and I wanted to try and develop a tool to address the issues.

Thankfully a dash of Emacs, a bit of ELDoc and a giant pinch of OmniSharp provided a pretty comprehensive solution. ELDoc shows information about the symbol at point in the echo area. It didn’t take long to get OmniSharp and ELDoc working together, and the result is very handy even if you don’t use var.

Some examples:

Here we can clearly see the type that has been assigned to myTween in the echo area, even though we’ve declared it with var.

And here we can see the complete function signature and return type of Go.to, which makes understanding the code around the call easier, especially in the presence of heavily overloaded methods.

And that’s it! ELDoc support is in my OmniSharp fork on github, and it will hopefully get pulled across to main soon. I hope someone finds it useful.

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:

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

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.

UPDATE!

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.

The Great Android Test 2012

It sounds like some sort of desperate attempt to gain geek credibility, but I’ve been using smartphones and PDA’s for years. My desire to have my very own tricorder took me through the joys of an HP Jornada, a Compaq iPaq, a Dell Axim, a Palm Treo, and a couple of HTC Windows Mobile 5 and 6 based devices. I held out against the iPhone incursion for as long as I could, until I succumbed to the siren song of the 3GS.

The funny thing is that, for someone who changed device every 6 or 12 months, I’ve now had the same 3GS for nearly 3 and a half years. The combination of solid hardware and an active ecosystem meant that, despite the temptation of a higher res screen, I’ve not really seen the point in upgrading. Buying an iPad probably helped as well.

Anyway, the 3GS is getting slower and slower, and the battery has suffered from about 1500 charge cycles, so it’s time for a replacement. And being a gadget whore, I thought I’d check out the competition before lazily falling back into bed with another iDevice.

First up was the HTC One X. I’d loved my previous WinMo HTC devices, and I’d heard about the lovely screen on the One X, so I was excited. When I got it, however, I took an immediate and not entirely rational dislike to it. The hardware is solid and the screen is wonderful, but there were very quickly some minor annoyances. The power connector is at the side instead of the bottom, making charging while in a case a challenge. There’s no physical ‘home’ button, and the power button is way up at the top, making it hard to reach on such a big phone – so even turning the thing on and off was a little bit annoying. The major issue, though, was the software, although weirdly I couldn’t pin down exactly what it was that I didn’t like. It was like looking at Mickey Rourke 20 years ago and now, and trying to work out exactly what had gone wrong; it just felt lumpy and misshapen.

So, that went back and along came the legally contentious Galaxy S3. This was a very different experience – slick, smooth, well thought out. Some people complain that it’s too plasticky but, coming from a 3GS, that isn’t something I noticed particularly. There’s a physical home button, the power button and power connectors are in sensible places, and the screen, like the One X, is wonderful. And though there are alot of complaints about Touchwiz, the software seemed much more polished to me, even if there are a fair number of Samsung specific apps I have no intention of ever touching.

Widgets and screens
Things I absolutely love about the S3, and indeed the wider Android experience, are:

• That huge screen. Going back to my 3GS is difficult. There’s a chance it might be slightly too big, but so far I haven’t tired of it (although my right pinky is getting a little sore from anchoring the bottom while doing big stretches).
• Widgets. I love being able to grab information at a glance, and Android widgets are fabulous for that – on opening my phone I can check out the weather, the stock market and my agenda for the week, without touching a single app icon.
• Differentiating between apps on your phone and shortcuts to launch them. On iOS the apps and their launch icons are one and the same thing, leading you to stuff apps you don’t use very often into poorly named folders. On Android you have a special ‘apps’ manager where all your apps really exist, leaving you free to keep your main screens uncluttered.
• Proper background multitasking. Not quite as useful as I thought it might be, but as someone who uses a newsreader all the time, it’s good to know that it’s always going to be up to date.
• Not having to pay an absurd amount of money to get an extra 16gb of storage. £70 to go from 16gb to 32gb is one of those examples of Apple hubris that never gets old.

Unsurprisingly, after 3.5 years of iPhoning, I have one or two gripes:

Useful notifications on the lock screen.
I like to pin-protect my phone, and as I mentioned above I’m a sucker for seeing lots of useful information with as little effort as possible. iOS has a killer feature for me here – all new emails, texts and missed calls are shown on front screen as soon as you touch the on button.

Here’s an example:

The sort of information I want to see on a lock screen.

On Android by default, the best you get is an icon telling you how many missed emails you have. There’s the pull-down notification bar (which Apple shamefully ripped off in iOS 5) which shows alot more info, but that groups emails together, once again leaving me with the certain knowledge that I have some emails, but no information on what they are.

After hours of looking around there’s an app called Executive Assistant that seems to do most of what I want, but there are still problems. Most annoyingly, because Google locks down the email database from third party apps, EA has to fetch emails itself, which both messy and a waste of battery. It also doesn’t clear the list of new emails automatically on unlock, so you have to clean it out manually.

No decent email client
I was enormously surprised by this, given Google’s background, but the stock email apps in Android seem a little… sucky. Yes there’s the GMail app, but I’ve personally never particularly liked the GMail interface, and like many people I have other email accounts. There’s the stock email app, which is okay but does threaded conversation views rather clumsily. On the app store, K9 is a nice free alternative, but that doesn’t do threaded conversations at all. Ultimately Maildroid looks like the best option – good email threading, fast delivery, nice interface.

However, none of them do as good a job as the stock iOS mail of squeezing emails into a small screen space. If you get emails with lots of embedded pictures (Amazon being the email nemesis in this regard), iOS does its best to ensure you never have to scroll horizontally. All of the Android apps behave as though you’re at your desktop, looking at things through a very narrow web browser. Here’s an example of what I mean.

Minor things
There are a couple of other niggles too:

• Scrolling up and down is still jerky. On my old, slow 3GS scrolling is still, always, silky smooth. In Android it’s lumpy, despite the hardware being 10x as fast and having 10x as much ram. I hope that Jelly Bean’s slightly tardy and unfortunately named ‘project butter’ will fix that.
• Lack of consistency. The S3 comes with quite a few stock apps. In addition, once you’ve downloaded a new email client, a new browser, tried to fudge the notification experience into something a little more helpful, etc, the core, day-to-day phone experience feels inconsistent. That’s probably partly my fault for having trying to contort the OS into my pre-existing usage patterns, but all the same, it makes things feel unpolished.
• Minor app gaps. I miss Toodledo. I miss Alienblue (BaconReader isn’t quite as friendly).
• Backups. With iOS I know that, should I lose my phone, everything has been backed up to the cloud, and I can remotely wipe the original phone. It could be my unfamiliarity with Android here, but I have absolutely no idea whether or not things are backed up and, even if they are, if that backup is going to be global to all Android phones or specific to Samsung. I also can’t tell if I can wipe it or not.
• I have a 3GS that’s nearly 3.5 years old and it’s running the latest version of iOS. Jellybean came out 3 months ago and, while there’s a rumour it’s coming to the S3 any moment, nobody really knows. Apple knows how to make me feel that my phone will last.

Conclusion
My conclusion, at the moment, is slightly inconclusive. Android is clearly a very capable platform and, once you’ve seen the S3 screen and experienced the joy of live widgets, iOS seems like a very dull place. At the same time, some very core parts of my phone experience are lacking on Android – lock screen notifications and a nicely integrated email client being the being main ones. At the moment I’m inclined to fall back to what I’m more familiar with, but that doesn’t seem as much fun…

Emacs and Unity Every Day

As I may have mentioned before, I like using Emacs. When working on Fable we were of course entirely based around the glorious Visual Studio, since the XBox and the 360 required it, and I started out using Emacs largely for editing Python and Lua code; we used those languages for various tools and scripting duties and Visual Studio at the time didn’t have very good support for ‘other’ languages. Gradually I drifted into using org-mode, then into eshell, and eventually I got to the point where I started missing certain features in other editors. Yes, even the glorious Visual Studio.

These days I’m working on a Mac, using Unity. I tried to use MonoDevelop but found it to be slow and clunky, and not being able to view two files at the same time was very frustrating. Eventually I switched entirely over to using Emacs. It wasn’t easy at first, and I still lament the lack of a decent autocompletion system, but in general I’m very happy with the workflow.

You don’t spend numerous years using Emacs without picking up a few customisations and I thought it would be worth documenting a few of the ones I use most often. If anyone finds it useful, I might dip further into the recesses of my dotemacs file.

So, here we go; Emacs things that I use every day.

Evil mode
evil-mode is a fabulous vi emulation layer in Emacs. I’m pretty new to it, and I originally turned to it in a last ditch attempt to cope with some RSI issues I’d been developing (at this point I have probably bought pretty much every ergonomic keyboard in existence). I’m not sure if it helps the RSI, but it has certainly helped my coding speed. A side benefit is that, while Emacs is incredibly flexible, it’s very easy to run out of keybindings for all your custom functionality. Evil-mode and it’s modal system largely makes that problem go away.

Ace jump
Inspired, I believe, by a vim plugin called from Easy Motion, ace-jump allows you to jump to any character on screen in (usually) 3 keypresses. It’s a little difficult to explain how, so I’ll skip straight to a demo of it in action. I hit space (my personal activation key in evil-mode), select a character to jump to (in this case ‘p’). Ace-jump highlights every ‘p’ there is and gives it a unique letter. I choose the one I want (in this case ‘n’) the character jumps to the correct location.

In that particular example, I’m jumping to any character on the screen which can create alot of hits, but there are other ways to call it which only highlight characters at the beginning of words.

It’s looks a bit mental at first, but once you’ve used it there’s no going back.

Mark Multiple
Another toughie to describe in text, mark-multiple allows you to select a section of text and then select further matching sections and edit them all simultaneously. If you’ve ever used Sublime Text you’ll be familiar with it. Here’s an example:

Here I hit v to select the terminating semi-colon, M-j to select further semicolons below, c to change the selection, and then type in the new code. There are other ways to achieve the same thing, of course, but mark-multiple is nice and tactile.

Helm

This used to be called ‘Anything’, and it’s essentially a generic quick jump system for Emacs, and it’s easily extended. For example, I have a simple custom project management system to allow me to easily compile projects, select which files go into a tags file, etc, and I use Helm to select files anywhere in my project, regardless of whether or not they are already open. Again, a simple example should suffice:

In this I hit C-x f to trigger the helm file finder, and type in part of the file I’m looking for. It shows files in my project, recently accessed files, open buffers; once I’ve narrowed down the selection enough I can then select using the cursor keys and hit enter to select the file.

Yasnippet
Alot of coding is repetitive stuff, and TextMate’s ‘snippets’ innovation was a great way of tackling some of the more tedious bits. The canonical Emacs implementation yasnippet expands on that, allowing you to create some very sophisticated code templates. Previously I’ve struggled to get it in my workflow – remembering the exact trigger phrase for an expansion never worked for me, and autocompletion often got in the way. I’ve recently discovered that you can trigger a snippet manually, however, and then use fuzzy-matching via ido to choose the right snippet. Example below:

In this example I’m hitting C-c s to trigger yasnippet, typing ‘fore’ to find the foreach expansion and hitting enter – it creates the skeleton and then I tab through the editable sections, filling them in as I go, with the last tab placing me in the braces. When you’re spending all day writing classes with conditions and loops and methods, this can be a big time saver.

Flymake
Something you may have noticed in one or two of the examples above is that I get syntax errors highlighted on the fly. This is the magic of flymake, which continually compiles the project in the background. I’ve got it hooked up with and a script to compile the Unity project, and it makes for a very smooth Unity coding experience. Errors underline in red as you type, the error message shows up in the minibuffer when you move the cursor into position, and it disappears when you fix it. Hardly revolutionary, but a nice productivity boost. It also seems to catch more genuine issues than the ‘on-the-fly’ error checker built into MonoDevelop, which is nice.

Shaderlab mode
Shaderlab-mode is a custom mode for editing shaders for Unity. It’s relatively basic, but it handles syntax colouring and indentation, which is all I really care about.

Wrapping it up
The upshot of this is that I spend 90% of my day in Emacs – from the start of the day when I check my todo.org list of tasks, to the edit-compile cycle for csharp, to editing shaders; I rarely leave Emacs, and when I do it’s usually just to tab on over to Unity to test out my changes.

I believe all of these extensions are available via ELPA, in marmalade or milkbox. Regardless, pulling it all together can take a little time, so I thought it might be worth sharing the details of how that’s done in my config. I’ve cobbled alot of this from various places on the intermawebs, notably http://dnquark.com/blog/2012/02/emacs-evil-ecumenicalism” title=”here”>here and here.


(require 'evil)

;;This gives you all the normal Emacs editing commands when in insert-mode
;;This eases the transition somewhat.
(setcdr evil-insert-state-map nil)
(define-key evil-insert-state-map
(read-kbd-macro evil-toggle-key) ‘evil-emacs-state)

(define-key evil-insert-state-map [escape] ‘evil-normal-state)

;;Not sure why, but semicolon started misbehaving for me when in insert mode.
(define-key evil-insert-state-map (kbd “;”) ‘self-insert-command)

;;Make evil-mode up/down operate in screen lines instead of logical lines
(define-key evil-normal-state-map (kbd “j”) ‘evil-next-visual-line)
(define-key evil-normal-state-map (kbd “k”) ‘evil-previous-visual-line)

;;Exit insert mode by pressing j and then k quickly
(setq key-chord-two-keys-delay 0.2)
(key-chord-define evil-insert-state-map “jk” ‘evil-normal-state)
(key-chord-mode 1)

;;If you work in camelCase or use underscored_names, this is very helpful
(evil-define-motion evil-little-word (count)
:type exclusive
(let ((case-fold-search nil))
(forward-char)
(search-forward-regexp “[_A-Z]\\|\\W” nil t)
(backward-char)))

(evil-define-motion evil-little-word-backward (count)
:type exclusive
(let ((case-fold-search nil))
(backward-char)
(search-backward-regexp “[_A-Z]\\|\\W” nil t)))

(define-key evil-normal-state-map (kbd “, b”) ‘evil-little-word-backward)
(define-key evil-normal-state-map (kbd “, w”) ‘evil-little-word)
(define-key evil-operator-state-map (kbd “, w”) ‘evil-little-word)
(define-key evil-operator-state-map (kbd “, b”) ‘evil-little-word-backward)

;;Not sure why this isn’t the default – it is in vim – but this makes C-u to go up half a page
(define-key evil-normal-state-map (kbd “C-u”) ‘evil-scroll-up)

;;Allow quick manual triggering of snippets
(define-key evil-normal-state-map (kbd “C-c s”) ‘yas-insert-snippet)
(define-key evil-insert-state-map (kbd “C-c s”) ‘yas-insert-snippet)

;;Toggle comments
(define-key evil-visual-state-map (kbd “, c”) ‘whole-line-or-region-comment-dwim)
(define-key evil-normal-state-map (kbd “, c”) ‘whole-line-or-region-comment-dwim)

;;Easy access to the mark multiple library when in visual-mode
(define-key evil-visual-state-map (kbd “M-j”) ‘mark-next-like-this)
(define-key evil-visual-state-map (kbd “M-k”) ‘mark-previous-like-this)

;;Ace jump stuff. Honestly, I just use Space 99% of the time
(define-key evil-normal-state-map (kbd “SPC”) ‘ace-jump-char-mode)
(define-key evil-normal-state-map (kbd “, , w”) ‘ace-jump-word-mode)
(define-key evil-normal-state-map (kbd “, , c”) ‘ace-jump-char-mode)
(define-key evil-normal-state-map (kbd “, , l”) ‘ace-jump-line-mode)

(define-key evil-operator-state-map (kbd “, , c”) ‘ace-jump-char-mode)
(define-key evil-operator-state-map (kbd “, , l”) ‘ace-jump-line-mode)

;;Personally I like ace-jump to be limited to the window I’m working in
(setq ace-jump-mode-scope ‘window)

;; Remap org-mode meta keys for convenience
(mapcar (lambda (state)
(evil-declare-key state org-mode-map
(kbd “M-l”) ‘org-metaright
(kbd “M-h”) ‘org-metaleft
(kbd “M-k”) ‘org-metaup
(kbd “M-j”) ‘org-metadown
(kbd “M-L”) ‘org-shiftmetaright
(kbd “M-H”) ‘org-shiftmetaleft
(kbd “M-K”) ‘org-shiftmetaup
(kbd “M-J”) ‘org-shiftmetadown))
‘(normal insert))

(evil-mode)

Most of that should be self explanatory with the comments. One thing to mention is that this makes use of the excellent keychord.el and comment-dwim both also available via ELPA repository. Keychord allows you to combine arbitrary keypresses into triggers, and it’s what allows the ‘jk’ trick above. There’s lots of other stuff I use too – org, nav, bm, window-number, winner – and lots of personal customisations, but I’ll leave those for another day.

The main thing I really miss is proper ‘correct’ autocompletion for C#, which Visual Studio spoiled me with for years. Someone has created a plugin for Sublime, called CompleteSharp, which uses a standalone commandline program to load up your assemblies and provide completion information, and I’m sorely tempted to write some Emacs hooks for it. If only I had the time…