Emacs was async before async was cool

Michael Herstine (IRC: sp1ff)

The following image shows where the talk is in the schedule for Sun 2022-12-04. Solid lines show talks with Q&A via BigBlueButton. Dashed lines show talks with Q&A via IRC or Etherpad.

Format: 18-min talk followed by live Q&A (https://emacsconf.org/current/async/room)
Etherpad: https://pad.emacsconf.org/2022-async
Discuss on IRC: #emacsconf-dev
Status: Talk captioned

Times in different timezones:
Sunday, Dec 4 2022, ~2:20 PM - 2:40 PM EST (US/Eastern)
which is the same as:
Sunday, Dec 4 2022, ~1:20 PM - 1:40 PM CST (US/Central)
Sunday, Dec 4 2022, ~12:20 PM - 12:40 PM MST (US/Mountain)
Sunday, Dec 4 2022, ~11:20 AM - 11:40 AM PST (US/Pacific)
Sunday, Dec 4 2022, ~7:20 PM - 7:40 PM UTC
Sunday, Dec 4 2022, ~8:20 PM - 8:40 PM CET (Europe/Paris)
Sunday, Dec 4 2022, ~9:20 PM - 9:40 PM EET (Europe/Athens)
Monday, Dec 5 2022, ~12:50 AM - 1:10 AM IST (Asia/Kolkata)
Monday, Dec 5 2022, ~3:20 AM - 3:40 AM +08 (Asia/Singapore)
Monday, Dec 5 2022, ~4:20 AM - 4:40 AM JST (Asia/Tokyo)
Find out how to watch and participate


While async is all the rage in the JavaScript, Go and Rust communities, Emacs has had the ability to (certain) asynchronous processing all along. I learned this while writing an Emacs package to program to my music server's API.

Music Player Daemon is a project that does what it says: hangs out in the background & plays your music. It has an API that I wanted to call from Emacs. I had just learned async Rust, so I decided to see if I could do something similar here. It turns out I could: I wound-up writing a little async runtime that allows callers to "send" commands to the daemon by queueing them up and returning immediately. In the background, as output from previous commands comes in, new commands are dequeued and sent.

This required callers to provide callbacks in order to receive the results of their commands, which led to a situation all too familiar to Javascript programmers: callback hell. The coda to my story was (finally) coming to understand Lisp macros in order to extend Emacs Lisp with a more convenient construct for sending multiple commands.

This talk will dive into the details of the Emacs Lisp process API, specifically the Low-Level Network Access API, with illustrations as to how it can be used to build an asynchronous queue. It will also introduce Lisp macros and how powerful they can be.

Michael is a developer and long-time Emacs user from the San Francisco Bay area. He hacks in C++, Lisp & Rust and thinks a lot about writing provably correct code. You can find him at:

Questions or comments? Please e-mail emacsconf-org-private@gnu.org