the wanderings of a supposed digital native

Menu

Boutique modes

I’ve recently started a new job at Linaro which has been keeping me very busy. My role combines the low-level fun of Dynamic Binary Translation that I so enjoyed at Transitive and the fact Linaro is a fully Open Source company. I work directly on the upstream projects (in this case QEMU) and with the project community. In many ways it’s my ideal job.

Of course I’ve quickly built up a reputation as the Emacs guy in the office surrounded by a sea of VIMers although one of the guys does profess a desire to learn Emacs “one day”.

One of the first things I did was move all my email into Emacs. I’d long been dissatisfied with the state of Thunderbird (and previously Evolution) that I took the opportunity to migrate to mu4e. I spend my days slinging patches and going through mailing lists so I really appreciate being in my editor while I do that.

I have also started streamlining some of my work-flow with a few specialised extensions to Emacs. I think I’m finally comfortable enough with elisp to have a pretty good stab at solving most problems. I’m also appreciating the ability to leverage the mass of Emacs code under the hood to make incremental tweaks rather than solve everything at once. I thought I might give you a tour of the code I’ve written so far.

First up is risu-mode. RISU is the code testing tool we’ve been using to verify our aarch64 ARM work in QEMU. The .risu file is a template that’s used to specify instruction patterns that the tool then uses to generate random code sequences with. risu-mode is really just a bunch of regex expressions wrapped in the mode machinery that highlights the elements on the page. It doesn’t sound like much but when you are working through a bunch of patterns looking for bugs it’s easier on the eye when the different elements are coloured.

Next thing I wrote was my own QEMU mode which is a simple comint-mode based mode for launching QEMU system emulation. It’s still very rough and ready as I’m mostly working on user emulation but I suspect it will be handy once I start on system emulation stuff.

Finally there is lava-mode. LAVA is Linaro’s automated test and validation framework. Although it already provides command line and web interfaces I thought it would be nice to launch and track test jobs from within Emacs itself. The job control files a JSON based so I built on the existing json-mode and a slightly patched version of xml-rpc.el to add job submission. I’ve started a simple job tracking mode that uses the tabulated-list-mode framework and eventually I’ll link it into the tracking library so job completion will be as seamless as my IRC work-flow.

So there you have it, a bunch of code that may well not interest anyone else but shows how Emacs provides a very rich base of functionality on which to build up tools that are useful to you.

Does anyone else want to share an example of their esoteric extensions? What’s the most obscure thing you’ve built on top of our favourite text editor?

3 Comments

Here’s some advice I wrote for interrupting U-Boot’s autoboot sequence on five boards of a multi-board system, all within the five second timeout. It’s probably esoteric even in the embedded world since the need to stop multiple boards at once is rare, but it’s very useful within my workflow.

I can see that being very useful for embedded stuff. I must admit I’ve tended to shy away from advice based stuff because of the scary warnings on the wiki against using it. Is it essentially a way of wrapping any given function?

Yeah, basically. In this case I wanted to modify term-emulate-terminal’s behaviour, but only when the stop-autoboot mode is enabled. term-emulate-terminal is a huge function built into Emacs so hacking a custom version in ~/.emacs.d/init.el wasn’t really an option. Using advice, the functionality remains portable to newer versions of Emacs/term-emulate-terminal.

Advice is really powerful, but also can get really complicated. For example, I remember thinking it was weird that I had to run ad-update after ad-disable-advice, and ad-activate after ad-enable-advice (there may be a better way of doing the dynamic activation/deactivation). But I’ve found advice useful for portably wrapping functions I don’t want to patch directly.