Introspecting Glue Code


Writing glue code is easy. Writing it well is harder.

Glue code is particularly common when developing editor plugins: you want to leverage the existing tools, often via a command line interface.

When bugs occur, it’s hard to know where the fault lies. Is this an issue with your glue code, or the underlying tool? We frequently face this problem with emacs-racer. Users feel powerless: they don’t know if they’ve misconfigured something, if the glue code is wrong, or if they’ve hit an genuine racer bug.

It turns out that flycheck already has a great solution to this. Flycheck can actually tell you why it couldn’t run a checker!

M-x flycheck-select-checker

Looking at flycheck, I realised this was exactly what emacs-racer needed. I built a M-x racer-debug command that tells you exactly what happened, and how to reproduce the issue outside of Emacs.

M-x racer-debug

This makes it much easier to see what racer is doing. Not only is it great for bug reports, but it helps us develop new features too. Developers can see exactly what data we receive from racer.

I’m still surprised by the versatility of introspective tools. When building functionality, it’s incredibly useful to be able to ask ‘what just happened?’. Debuggable debugging tools are a superpower.

Recent Posts

Helpful: Adding Contextual Help to Emacs

Suggest.el: Synthesising Constants

Optimising Dash.el

These Weeks in Remacs II

Synthesising Elisp Code