notes from /dev/null - emacs

Announcing shazam.el

2026-08-24T14:00:00-07:00

Continuing my explorations on malleable computing with Emacs is examining access to OS/Platform-specific resources, in this case with macOS. macOS provides a number of mechanisms for high-level inter-process communication, among them AppleScript & Automator Actions (now considered legacy but still maintained) and App Intents, Entities & Shortcuts (introduced in macOS 13 and considered by Apple a replacement for the former).

This post both announces and covers the implementation of an Emacs integration with the Shazam music recognition service that is packaged with macOS. This Emacs integration is called shazam.el (https://github.com/kickingvegas/shazam) and is now available for installation via MELPA.

To understand the shazam.el implementation, the following background information is provided.

Background

Shazam is a music recognition service that is implemented across Apple's different platforms (macOS, iOS/iPadOS, watchOS, tvOS). This service provides a shortcut action (Recognize Music) which is implemented using the following APIs:

App Intent: An expression of an app’s capabilities to the system (in this case the ecosystem of Cocoa-based applications), and contains code to perform that action (App intents | Apple Developer Documentation).
App Entity: Information provided to the system about your app’s data, or about concepts related to your app’s data (App entities | Apple Developer Documentation).
App Shortcut: A workflow (including UI) for orchestrating App Intents and Entities (App Shortcuts | Apple Developer Documentation). There are a number of ways to access a Shortcut, among them via the Shortcuts app or Siri.

With the Recognize Music shortcut action we can realize the Elisp package shazam.el.

Implementation

A Shortcut (aka workflow) defined in the Shortcuts app can be invoked via command line as follows:

shortcuts run "<shortcut name>"

where “shortcut name” is the name given to a Shortcut enclosed by double-quotes.

If the Shortcut is intended to write to stdout, then the shortcuts command line utility must be run into a pipe.

shortcuts run "<shortcut name>" | cat

The above incantation lets Emacs run a Shortcut.

The Shortcut used by shazam.el invokes the Recognize Music action and does some work to transform the Shazam search result into a JSON dictionary. The JSON dictionary is written to stdout (iCloud Shortcut: “Identify Music JSON”) which can be read by Emacs and processed.

The sequence diagram below shows the overall integration workflow between Emacs and Shortcuts for shazam.el.

Features

Details on all the features provided by shazam.el can be found in its User Guide. Of note is that once the Shazam search result is deserialized, its content can be processed into a variety of formats. shazam.el takes advantage of this by storing recognized search results into an Org file, using Org markup and properties to store metadata provided by each result. Users can subsequently peruse this history file at their convenience.

Closing Thoughts

This work builds off the explorations in malleable computing with Emacs described in my prior posts:

There is not a lot of Elisp to shazam.el as shown in the cloc result for it:

github.com/AlDanial/cloc v 2.10  T=0.01 s (143.3 files/s, 35402.8 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Lisp                             1             50             38            159
-------------------------------------------------------------------------------

Most of the challenge in building shazam.el was understanding how start-process worked to asynchronously run the shortcuts command line utility.

A downside to using a Shortcut (workflow) is the requirement to use a binary code-signed representation that is accessed via the Shortcuts app. This makes it less flexible than AppleScript where declaring behavior can be done in plain text. For example, the now-playing.el package can remote-control the Music app via AppleScript that is directly invoked from Emacs built with support for ns-do-applescript. In contrast, accessing contemporary macOS app behavior that is exposed via Intents and Entities requires installing (or creating) a binary code-signed representation (the Shortcut). This adds an extra step (or steps for installing multiple shortcuts) to build an integration with Emacs or any other orchestration tool.

References

Simplifying Setup for Casual

2026-08-18T09:20:00-07:00

Since its inception, Casual required individual setup for each module it supported. This seemed fine at the start when the module count was low. Now weighing in at 26 modules, there is admittedly a lot of setup.

Not anymore. Starting with the latest Casual v3.0 update, there is now a convenience command to setup all Casual modules: casual-init.

Use the following Elisp to replace all the previous setup code:

(require 'casual)
(casual-init)

You can configure which modules to setup via the customizable hook variable casual-init-hook, a list of hook functions each associated with a module. Having a module hook function present in casual-init-hook tells casual-init to setup that module.

Editing casual-init-hook is straightforward using the customize checkbox interface shown below.

More information about installation and setup of Casual can be found in the Casual User Guide.

Bumping to 3.0

Because the recommended setup has significantly changed, I’ve decided to bump the major version to 3.0.

That said, there are no functional changes to Casual and all the prior individual setup still should work without change. For existing users of Casual, I highly recommend migrating to casual-init as it allows for removing individual setup code.

A significant amount of manual testing was required to verify lazy-loading behavior in casual-init. While best effort was made to avoid unpleasant surprise, if something shows up, please file an issue to let me know.

Casual v3.0 update is now available on MELPA and NonGNU ELPA.

It costs money to make, enhance, and maintain Casual as ideologically free software. If you enjoy using Casual, please consider buying me a coffee to help support its development and maintenance. Thank you!

Announcing now-playing.el, an Emacs interface for the macOS Music app

2026-08-03T10:55:00-07:00

For me, listening to music whenever I’m working on a computer is a commonplace, daresay essential activity. Much of my work is done using Emacs, so the idea of having it control music playback to mitigate an app switch seemed reasonable. Such was the motivation for my latest project, now-playing.el, a Transient interface for the macOS Music (nee iTunes) app.

now-playing.el takes inspiration from the many mini-client interfaces provided by Apple to control the Music app. The idea was to have a compact and simple interface:

Show what is currently playing (song, artist, album)
Offer basic controls (play/pause, next/previous track, volume control)
Optionally log what was played.

now-playing.el takes advantage of AppleScript support in the Music app, providing the needed controllability and observability of it from Emacs. The sequence diagram below illustrates how these programs relate to each other by showing a request/response transaction between Emacs and the Music app using the osascript command line tool.

If Emacs is built with NextStep (NS) support, then Emacs can send a direct AppleScript message to the Music app via ns-do-applescript to avoid making a shell call to osascript.

State synchronization for now-playing.el is fairly simple, with client updates done in a pull fashion. More details about what now-playing.el can do can be found in the now-playing.el User Guide.

Closing Thoughts

It is not coincidental that writing this mini-client for the Music app works into my recent explorations and musings on malleable computing with Emacs. As of this writing, now-playing.el weighs in at 326 lines of code (cloc measured), taking full advantage of Elisp libraries to construct the following client subsystems:

UI: Transient for menu, cus-edit.el for customization UI
Client Edge: shell-command-to-string to osascript, ns-do-applescript
Local Database: Elisp variables

now-playing.el explores integration with AppleScript, itself a mechanism to allow for orchestration between Cocoa applications. Expect some future posts documenting my explorations in this area, particularly with the more contemporary Apple Shortcuts and Intents.

now-playing.el v1.0 is now available on MELPA.

Malleable Computing, Emacs, and You

2026-07-22T14:00:00-07:00

It all started with a routine task. I use GitHub issues for all of my public-facing projects but my preference is keeping track of things in Org Agenda. To reconcile the two, I would manually copy over the GitHub issue to an Org file, typically the title and description, like an animal.

Despite this separation, the duplicated issue allowed me to treat it as a scratchpad for anything I could express in Org. In this way, I used the duplicated issue in Org as both a dedicated area to take notes and a “staging” area to compose follow-up comments that I’d want to share in the public facing issue.

I manually copied for far longer than I care to admit. Repeat a task enough times in Emacs and the inevitable thought arises: “I should automate this.”

This post recounts how I automated this task and in doing so, highlight the malleable computing capabilities of Emacs. It should also be considered a follow-up to my earlier post “In Emacs, Everything Looks Like a Service”.

Requirements

An essential question to ask in any automation exercise is “What do I want done?”

I wanted to be able to:

Easily copy a GitHub issue (title, description, some metadata) as an Org task that can be tracked in an Agenda view.
Work primarily from Emacs to minimize the context switching between it and a web browser.
Express my thoughts in Org syntax.
Create a new GitHub issue.
Avoid dealing with GitHub authentication.
From Emacs, open a GitHub issue in a web browser.

Another essential question to ask is “What do I not want to do?”

Install or write a full-featured GitHub client.
- Worry too much about synchronization logic between local (Emacs) and server (GitHub) state.
Spend a lot of time on this (ideally have something working in a day, no more than a week).

Specification

With the above requirements in place, the next question is “how do I build this?”

For this particular exercise, I decided to leverage my existing install of the GitHub command line utility gh. The benefits for this are:

GitHub authentication is delegated to gh; no need to mess with it directly from Emacs.
Emacs can treat gh as a REST service to GitHub as shown in the diagram below

To flesh out the rest of our tool, we can leverage using different Elisp packages and programs:

For the user interface, the Transient and Variable Pitch Table (vtable) packages are used for menus and display respectively.
For Org to Markdown translation, ox-gfm will be used.
For Markdown to Org translation, Pandoc will be used.
Elisp native JSON support will be used for deserializing the JSON responses from gh.

Implementation

The implementation of the above is published as the package gah with its source available for examination in the file gah.el. Of note is the function gah-request-issues which does the work of retrieving GitHub issues via gh as shown below.

(defun gah-request-issues (repo)
  "Request issues for REPO."
  (let* ((fields gah-browser-fields)
         (cmd-list (list "gh"
                         "--repo"
                         (format "'%s'" repo)
                         "issue"
                         "list"
                         "--limit"
                         (number-to-string gah-request-issue-count)
                         "--json"
                         (string-join fields ","))))

    (json-parse-string (shell-command-to-string
                        (string-join cmd-list " "))
                       :null-object nil)))

Consider the high degree of abstraction provided by gah-request-issues:

The list cmd-list forms the request (in this case, the arguments to invoke gh with).
shell-command-to-string dispatches the request to gh.
The returned JSON response is handled by json-parse-string to deserialize the JSON into an Elisp hash table.
All of the above is accomplished in less than 20 lines of code.

The returned hash table result is subsequently processed to populate a vtable as shown below. From the vtable, the user can navigate the list of issues with an ancillary window updated to show the details of a selected issue.

Multiple commands and functions working with said hash-table were made to satisfy the requirements above. They are accessible via the Transient menu shown below:

Malleable Computing Observations

As Elisp is a dynamic programming language, the above function (or some variant of it) can be coded and evaluated within a running Emacs session. In Emacs it is routine practice to prototype code behavior without the need to restart it. Contrast this with tools that are built with a static language and have no extensibility, where the edit-compile-debug development cycle must be applied to exercise behavior, provided the source code is available.

Emacs provides numerous ways to edit and evaluate Elisp code, among them:

A scratch buffer
An Elisp file
An Org source block
IELM REPL
Eshell
eval-expression (M-:)

Because there is no isolation between loaded Elisp code, all of it can be orchestrated together in an improvised fashion. Any program accessible to Emacs via shell further adds to this mix.

Provided high abstractions, the amount of code needed to be written for desired behavior can be small. At the time of this writing, gah.el has approximately 400 lines of code has been measured by cloc:

github.com/AlDanial/cloc v 2.08  T=0.01 s (146.4 files/s, 76550.1 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Lisp                             1             93             38            392
-------------------------------------------------------------------------------

It took me about 2½ hours to build the basic behavior I wanted (request issues from GitHub, then display) and the rest of the day to cover all the original requirements. Everything after that was just refactoring.

Motivated readers are invited to examine gah.el to understand its details. At this point though, I’d like to take the opportunity to muse on software engineering and malleable computing.

Software Scope - Some Percentage Anecdotes

The 90/90 rule posits that “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time”. Closely related is the Pareto principle (aka the 80/20 rule) as applied (or more mis-applied) to software development: only 20% of your features will be actually used by 80% of your users.

From control theory there is the concept of bounded input, bounded output (BIBO) stability. If the system is BIBO stable, then whatever input that is bounded will have an output that is also bounded.

Coupling these ideas together, if the functionality you want (BIBO stability) is within that 20% deliverable then you are positioned to get a desired result faster.

Unfortunately, this observation is not available for many producers shipping a tool that must satisfy a large audience. In Sinofsky’s post “What is Software Bloat, Really?”, he describes the product definition issues with shipping Microsoft Office, particularly with feature set. From their user research, they were led to this finding: “… the data was entirely conclusive: Most of Office was used. But no one person used the entire product.”

When discussing product definition, it is helpful to distinguish two informal dynamics: supply and demand.

With software that is only supply-provided (such as the case with MS Office), the weight of product definition is shouldered by the producer. If the producer wants to serve a vast audience, it is likely their feature set and corresponding development scope will be vast as well. On the demand-side, consumers can make requests for new features, but their prioritization is controlled by the producer. In this situation, the roles of producer and consumer are strongly delineated.

Malleable software, where users have agency to adapt and reshape their digital tools, offers a different possibility: producers provide the building blocks and let consumers make their own tools. In this, both existing code and programs are recombined to make new behavior. Stated another way, malleable software takes advantage of combinatorial explosion in that a desired subset of behavior can likely be found within the state space of combining existing libraries (in this case Elisp) with different programs. With malleable software, the roles between producer and consumer are less delineated. A consumer building a new tool out of malleable building blocks now must shoulder the weight of product definition.

Build for 1 or N

The scope to build for 1 vs N can be an order of magnitude with the kicker that N need not be large. Choosing to write code for another person (N=2) escalates concerns that could otherwise be brushed aside:

Error handling
Code maintainability
- Modularity/Reuse
Documentation
Unit and Integration Testing
Packaging
Distribution

Both a blessing and curse of malleable techniques is that they allow for “just good enough” capability. Malleable techniques encourage building for 1 as reaching a state of “it works for me” is often sufficient to declare victory.

For most software that is only supply-provided, building for N is a requirement. For most software built with malleable techniques, building for N is a choice.

Malleable Software and User Agency

Returning back to gah, the benefits of building for 1 are evident:

From within Emacs I can now easily:

Peruse GitHub issues for a specified repository.
Copy a GitHub issue into a Org file.
Create a new GitHub issue using Org syntax.
Open a GitHub issue in a web browser.

Implementing gah in Emacs was straightforward as I could leverage Elisp packages (both built-in and 3rd party) and external applications (gh, pandoc) to build it. Within a day I had a tool that did what I wanted. I did not have to ask for permission nor required privileged materials (source code) to build gah. With Emacs, I could just do it. Such individual empowerment advanced by malleable techniques is liberating in contrast to working with siloed applications with little to no integration between them.

Closing Thoughts

This post muses about the malleable computing capabilities provided by Emacs, showing by concrete example (gah.el) how new behavior can be created leveraging both code and program reuse in an improvised fashion. With measured expectations (requirements, feature set, audience), malleable techniques allow for building tools that would otherwise be infeasible without it.

Addendum 2026-07-23 11:30 PST

Doh. Because this started out as a personal project, I did not do any due diligence on the project naming. Turns out the name fj is already used as a client for Forgejo.

As such I've renamed my project to gah and amended this post accordingly. My apologies for any slights this has caused.

In Emacs, Everything Looks Like a Service

2026-07-09T23:40:00-07:00

A common refrain is that Emacs is an operating system (OS). This isn’t true, but what invites comparison to an OS is its ability to orchestrate applications and utilities above the OS kernel level. The diagram below suggests a truer picture of how Emacs’ relates to an OS and its capabilities.

Emacs’ built-in access to OS system services (file system, network, etc.) coupled with the ability to run other programs makes it routine to improvise client behavior within it. Because of this, Emacs users are able to accomplish many of their computing needs from the different client modes that have been made for it. This gives credence to the notion of “living only in Emacs.”

In this post, we’ll examine some of the ways Emacs lets you build a client. By the end of this post, you’ll hopefully be convinced that from within Emacs, everything looks like a service.

Client-Server Model

Let’s first provide some definitions.

The Client–Server model is a common computer interaction pattern where a task is partitioned between the provider of a resource (the service) and the requester of that resource (the client). The client issues a request to the server, and the server in turn returns a response as shown in the diagram below.

Depending on the implementation, the transaction (request + response) can occur over a network or be local to a system. Client-server models using a network has been most elaborated upon with REST-style software architectures. Shown in the sequence diagram below is a common implementation pattern for REST-style client server architecture.

Emacs as a Client

From the diagram above, there are three concerns the client is typically responsible for:

UI: User interface (if any).
Client Edge: Sub-system concerned with communication with the service. For networked clients, this is the network sub-system.
Local Database: Representation of data that is exchanged or synchronized with the server. How this data is managed is up to the implementation requirements.

For the above concerns, Emacs provides numerous libraries both built-in and third-party which can implement a client. Listed below are some built-in libraries with their respective links for further reading:

UI
Client Edge
- URL
- Socket (TCP/UDP)
- SMTP
- Serialization/Deserialization
  - JSON
  - XML
Local Database
- Collections
- SQLite

Requirements dictate the amount of complexity required to implement the Emacs client. If there is an existing command line utility that can do the “heavy lifting”, said utility can be reframed as a “service” that can be accessed via a shell call.

Elisp

All the libraries mentioned above are accessed through the Emacs Lisp (Elisp) programming language. Elisp is a dynamic programming language which allows for a high degree of improvisation during run-time. This capability allows for complex orchestration of any behavior that is available to Emacs, from Elisp functions to shell commands.

Example wttr.in client

wttr.in is a console-oriented weather forecast web-service. It supports JSON output so we can build an Emacs wttr command which will prompt for a location, make the HTTP request, process the JSON response and display the result in the mini-buffer.

The top-level command wttr is shown below.

(defun wttr (location)
  "Show weather conditions for LOCATION from `https://wttr.in' in mini-buffer.

Result is also stored in `kill-ring'."
  (interactive "sWhere (default: local): ")

  (condition-case err
      (let* ((url (wttr--request-url location))
             (jsondb (fetch-json-as-hash-table url))
             (msg (wttr--report-message jsondb)))
        (kill-new msg)
        (message "%s" msg))

    (error (message "ERROR: %s" (cdr err)))))

The wttr.in URL is constructed by the function wttr--request-url shown below.

(defun wttr--request-url (location)
  "Construct wttr.in URL with LOCATION."
  (let* ((base-url (url-generic-parse-url "https://wttr.in"))
         (encoded-location (string-replace " " "+" location))
         (query (format "/%s?0&format=j1" encoded-location))
         (_dummy (setf (url-filename base-url) query)))
    (url-recreate-url base-url)))

We can subsequently pass that URL into fetch-json-as-hash-table which does the heavy lifting of retrieving the URL and parsing the JSON response into an Elisp hash-table.

(defun fetch-json-as-hash-table (url)
  "Fetch URL with expected JSON response and return a `hash-table'."
  (let ((data-buffer (url-retrieve-synchronously url)))
    (if (not data-buffer)
        (error "Failed to fetch data from %s" url)
      (unwind-protect
          (with-current-buffer data-buffer
            ;; Move point past the HTTP metadata headers
            (goto-char url-http-end-of-headers)
            ;; Parse the remaining JSON buffer into a hash-table
            (json-parse-buffer :object-type 'hash-table))
        ;; Always kill the downloaded network buffer to prevent memory leaks
        (kill-buffer data-buffer)))))

Finally we can extract the desired values from the JSON response (jsondb) to populate the message that will sent to the mini-buffer.

(defun wttr--report-message (jsondb)
  "Generate weather report message from JSONDB."
  (let* ((area-buflist ())
         (nearest-area
          (wttr--get-first jsondb "nearest_area"))
         (area-name
          (map-elt (wttr--get-first nearest-area "areaName") "value"))
         (region
          (map-elt (wttr--get-first nearest-area "region") "value"))
         (country
          (map-elt (wttr--get-first nearest-area "country") "value"))

         (current-condition (wttr--get-first jsondb "current_condition"))
         (temp_c (map-elt current-condition "temp_C"))
         (temp_f (map-elt current-condition "temp_F"))

         (weather-description
          (map-elt
           (wttr--get-first current-condition "weatherDesc") "value")))

    (mapc (lambda (x)
            (if (and x (not (string-equal x "")))
                (push x area-buflist)))
          (list area-name region country))

    (format "%s: %s°C, %s°F %s"
            (string-join (reverse area-buflist) ", ")
            temp_c
            temp_f
            weather-description)))

wttr.el source

Closing Thoughts

At this point, hopefully you are convinced of the title assertion that from Emacs, everything looks like a service. Furthermore, many of the APIs offered by Emacs work at a high-level of abstraction. Consider that the lines of code for wttr.el weighs in at 67. (Result using the cloc utility.)

If that’s too much, then imagine an alternate implementation where the actual network request and JSON processing is done in a Python script called weather. Then the Elisp command to invoke it is just the code shown below.

(defun weather (location)
  "Call weather script with LOCATION and show result in minibuffer."
  (interactive "sWhere (default: local): ")

  (let* ((weather-cmd "weather")
         (cmd (if location (format "%s %s" weather-cmd location) weather-cmd))
         (result (shell-command-to-string cmd)))
    (kill-new result)
    (message result)))

With the above implementation, the shell command becomes effectively the “service” to make a request to.

As Elisp is a dynamic programming language, it can allow for integration of Elisp libraries with command line utilities in an improvised fashion.

This capability is compelling to users who recognize the opportunities it can offer.

Scheduling Future Tasks in Emacs

2026-06-24T12:25:00-07:00

Back when I had to run a lot of long-running simulations on Unix systems, I became an ardent user of the at command, which lets one schedule a program to run at a future date. I also used at to schedule different notifications, like sending a message to a pager (yer, how quaint).

Moving to macOS (nee OS X) changed that, as it disabled by default the at command due to battery life management. As I was unwilling to give up battery life for at, I learned to live without it. That was, until I learned that Emacs had run-at-time.

The run-at-time command does as it says on the tin: it will run a function at some future specification of time.

(run-at-time TIME REPEAT FUNCTION &rest ARGS)

That specification of time is “natural language-like” in that multiple string representations of time can be accepted, both absolute and relative.

The function can be anything Elisp offers, but running shell commands is what makes run-at-time a substitute for at, with some caveats.

Jobs that are submitted by run-at-time can be listed out via the list-timers command. You can cancel a job (actually a timer object) using the c key, bound to timer-list-cancel. Note that Emacs disables list-timers by default as it exposes timers that you should likely not mess with. Be forewarned.

Another caveat is that using run-at-time presumes that your Emacs session is still running at that future time. If you have Emacs running all the time (particularly as a server) then this should work without complication.

Example: Scheduling a macOS Notification

A common use I have for run-at-time is to send myself a notification at a future time. The way I prefer to be notified is using the macOS Notification Center. Here’s an example of what a notification looks like:

The above notification was sent using a macOS Shortcut I’ve defined named nota. Shown below is how nota is defined in the Shortcuts app.

A macOS shortcut can be invoked from the command line. We can wrap this capability in the Elisp function cc/run-nota.

(defun cc/run-nota (msg)
  "Run nota shortcut with MSG."
  (process-lines
   "shortcuts"
   "run"
   "nota"
   "-i"
   msg))

Finally we can schedule cc/run-nota with run-at-time through the wrapper command cc/notify-at.

(defun cc/notify-at (&optional start-time msg)
  "Send a nota notification with MSG at START-TIME.

This command invokes `cc/run-nota' with MSG at START-TIME passed into
`run-at-time'."
  (interactive)
  (let* ((start-time (if start-time
                         start-time
                       (read-string "Time: ")))
         (msg (if msg
                  msg
                (read-string "Message: "))))
    (run-at-time start-time
                 nil
                 #'cc/run-nota
                 msg)

    (message "Show notification “%s” in/at %s" msg start-time)))

Users wishing to install the nota macOS shortcut can download it via the following iCloud link:

nota shortcut (via iCloud)

Closing Thoughts

run-at-time is an underappreciated built-in which has given me much of what I used to use at for. If you use Emacs for implementing any kind of automation, you should include run-at-time as part of your toolbox for it.

Revisiting Emacs Keyboard Macros with a Mouse

2026-06-04T09:35:00-07:00

“No-code automation” has been in Emacs far longer than its usage as a term of art. Better known as keyboard macros, this feature has allowed Emacs users to achieve their bespoke needs for decades, all without needing to know a whit about Lisp. I can testify to this personally: though I’ve been using Emacs since the early 90’s, only in the past three years has writing Elisp played any part in it. For most of my Emacs journey, I got by with just making keyboard macros.

If you’re unfamiliar with them, here are two links you should get to know:

The official Emacs manual for keyboard macros ((emacs) Keyboard Macros)
Mickey Petersen’s post - “Keyboard Macros are Misunderstood”

My addition to the knowledge of those posts is to boost this fact: mouse events can also be captured by a keyboard macro. If you know where a command is in a menu, you can also record clicking on it. I think the ability to combine both keyboard and mouse events in a keyboard macro is compelling, so much so that I decided to emphasize this in Anju.

The recent Anju v1.5.0 release added the menu “Tools › Macro Recorder” to the menu bar as shown below.

With this, mouse enthusiasts can create and run keyboard macros without need to recall keybindings or deal with inconsistent command naming, as observed in Petersen’s post.

One thing that I TILed about keyboard macros in building this menu was the command list-keyboard-macros (see (emacs) Kmacro menu). This command is available in the “Macro Recorder” menu as the item “List macros”. This lets you manage multiple keyboard macros that have been defined during a session.

If this interests you, I invite you install Anju from MELPA and give it a try. Let me know what you think!

Opening macOS Finder Folders in Emacs with Scrim

2026-06-01T19:00:00-07:00

TL;DR

If you use both Scrim and Emacs on macOS, you can “Open in Emacs” a file or directory from Finder via the “Quick Actions” context menu. This is implemented as a macOS Shortcut, shared as an iCloud link:

“Open in Emacs” Shortcut iCloud Link

Motivation

I find macOS drag-and-drop operations from Finder to Emacs (in particular, the NS variant) to be frustratingly inconsistent.

Dragging a file or folder from Finder to a non-Dired buffer will visit it.
- Not always! This behavior can be mode-specific.
Dragging a file or folder from Finder to a Dired buffer will copy it.
Dragging a file or folder from Finder to the Emacs icon in the Dock will visit it in a new frame.

Add to that, drag-and-drop isn’t graceful with a long traversal path on a large screen.

Ultimately, what I want is a single consistent action to “Open in Emacs” a file or directory from Finder. This post describes a solution for achieving this using the Scrim and macOS Shortcuts apps.

Background

Scrim

Scrim is an Org protocol proxy app that I had published on the App Store last year. Implementing Scrim was largely an exercise in reverse-engineering emacsclient to be a macOS app. This is because macOS apps these days (macOS 10.14+) are packaged to execute as a hardened runtime (aka “sandboxed”). Among the many things a hardened runtime restricts is the ability for an app to exec another program outside of its sandbox (like emacsclient).

In lieu of that restriction, macOS provides different APIs to let apps work with other apps, among them Services (more below), Intents (a whole different topic worthy of another post), and custom URL schemes.

A custom URL scheme is what Scrim provides to allow other apps to do emacsclient-like things like opening a file. By design, Scrim does not surface all the capabilities of emacsclient such as arbitrary Elisp execution. The custom URL scheme itself is scrim://.

Currently the scrim:// URL scheme supports the following two actions:

Visit a file or directory (e.g. scrim://open?file=~/.profile)
Open an Info node (e.g. scrim://info?node=(eshell) Top)

For this post, we will concern ourselves with (1) visiting (opening) a file or directory.

Note that on a system where a custom URL scheme is installed, any app on that system can open said custom URL scheme.

Services

The macOS Services API allows an application to access the functionality of another.

Apple uses this API to provide tools to help orchestrate workflows between different applications, namely AppleScript, Automator, and Shortcuts. Note that as of this writing, AppleScript and Automator are in maintenance mode, and Shortcuts is intended to supersede Automator. Once a workflow is defined, it is usually accessed via a context menu sub-menu labeled “Quick Actions” or “Services”.

“Open in Emacs” Shortcut

With the above background out of the way, let's turn our attention to the Shortcut itself.

The shortcut invokes a Python script which forms the scrim://open?file custom URL and then opens it with the open command line utility.

import sys
from subprocess import call
from urllib.parse import quote

buf = "scrim://open?file={0}".format(quote(sys.argv[1]))
cmdList = ['open', buf]
call(cmdList)

This shortcut can be installed via iCloud link: “Open in Emacs” Shortcut iCloud Link.

When installed, the menu item "Open in Emacs" will appear in the "Quick Actions" sub-menu when the context menu is raised on an Finder item.

“scrim link” Shortcut

What if you want just the Scrim URL to open a file or directory instead? The shortcut "scrim link" shown above provides that, putting the URL into the system clipboard to paste into another native macOS app like Notes or TextEdit. Such apps that recognize custom URL schemes will treat the URL as a “live” link.

This shortcut is available at “scrim link” Shortcut iCloud Link.

Closing Thoughts

While the behavior of "Open in Emacs" seems modest, a lot of things need to happen under the hood to orchestrate the different apps required to make it happen on macOS. But taking a step back, I'd observe that this is not unique to just macOS alone. Other contemporary operating systems are following suit as seen with Snap (Ubuntu) and Flatpak for Linux, and UWP for Windows. Such isolating practices by OS vendors are not going away.

Running counter to this is the spate of interest in orchestrating apps and/or services together using AI tools, whose approach so far is to bypass all hardened runtime boundaries.

Then there is comparison to the Emacs ecosystem, where orchestration of apps (or rather modes) is routinely done via Elisp. By implementation circumstance there are effectively no concerns for security boundaries within the internals of Emacs.

There's a lot of ground to ruminate on, in particular software malleability and orchestration, which I intend to do with future posts on this blog.

Anju v1.5.0 Update

2026-05-28T10:00:00-07:00

Heads up for readers of this blog who are using Anju or are mouse-curious Emacs users. I’ve recently released the v1.5.0 update for it, now available on MELPA.

Many new features and enhancements are in this update as outlined below:

Context Menus
- Enhancements to selected text
  - Query Replace (Regexp)…
- Enhancements to Org mode support
  - Headline
    - Change to Body
    - Sort…
  - Item
    - Cycle Bullet…
    - Sort…
  - Table
    - Sort…
  - Copy as…
  - Link…
- Added support for Makefile mode
- Added support for Info mode
- Added support for Compilation/Grep mode
Main Menu
- Tools menu enhancements
  - Global Org Commands
  - Macro Recorder
- Edit › Delete menu enhancement
  - Delete Duplicate Lines

Users who work with both Org mode and Markdown formatted text should find interest in the Copy as… capability added to the Org mode context menu. This feature lets one use Org mode as the primary means of authoring text, exporting to Markdown (or another format) using a right-click mouse copy action.

Thanks to Marcin Borkowski whose post “Org-mode to Markdown via the clipboard”, inspired this feature.

Anju also provides a complementary command “Paste Markdown as Org” for Org mode which lets one paste copied Markdown text into an Org file, doing the conversion of Markdown to Org under the hood using pandoc.

In summary, this is a big release with many changes. I invite you to explore all the links above to see what’s available in Anju.

Using the Mouse for Emacs Rectangle Commands

2026-05-18T09:45:00-07:00

Of all the built-in editing commands in Emacs, the commands that work with rectangles delight me the most. Once understood, they can save effort in many situations.

That said, the biggest downside to rectangles is the amount of setup it takes to use them. As with many things Emacs, by default you have to memorize a bunch of keybindings to get anything done with them.

In Casual, I addressed the above downside by providing a Transient menu for rectangle commands. Since building that, I've come to use rectangle commands routinely. But even then, there is ceremony to set up a rectangle selection.

With my recent work on mouse-driven interactions in Anju, I’ve learned that rectangle selection is trivial via C-M-<mouse-1> dragging. Once selected, having a menu of rectangle commands makes working with them even easier. So I made one for the latest v1.4.0 update for Anju, now on MELPA.

The “Rectangle” sub-menu is available via the main menu bar “Edit” menu (as shown in the screenshot above) or via context menu. Using rectangle commands in conjunction with the align-regexp (“Edit › Align Regexp…”) and whitespace-cleanup (“Edit › Delete › Whitespace Cleanup”) can make short work of editing text that is laid out in columns. Anju makes both of these commands available from the main menu.

Side note: on using C-M-<mouse-1>, sometimes Emacs will only read M-<mouse-1> and do a secondary selection, leaving an unwanted highlight. Enter M-<mouse-1> to dismiss the highlight.

If you find Anju to be useful, please support its development by buying me a coffee. I’ve got a number of new features planned for it.

Enhancing Elisp Development with Context Menus

2026-05-11T11:00:00-07:00

As celebrated as Emacs is for its programmability, I find the actual process of developing Emacs Lisp (Elisp) to be quite underwhelming. Developing in Elisp has meant learning its libraries and idioms, which is to be expected. What I really don’t care for though are the arcane keybindings associated with doing basic things like evaluating, navigating (Xref), and debugging (especially debugging). While I’ve already committed to muscle memory most of said keybindings, I’d argue that having a mouse-based “point and click” interface is beneficial for both novice and experienced Elisp developers alike, as it lets one focus on the code and not on recalling the right key incantation all the time.

The addition of context-menu-mode in Emacs 28 has provided the opportunity to build a mouse-based UI for Elisp development and I’m happy to announce the availability of one in the latest v1.3.0 update to Anju, now on MELPA.

To get an idea of what’s available in the v1.3.0 update, here’s a screenshot of the context menu when normally editing an Elisp file where the point is on the symbol foo.

If foo is instrumented for debugging and run, the context menu is adjusted to provide Edebug commands as shown below.

The context menu enhancements provided by Anju take full advantage of built-in functions that identify context at point. Is the point on a symbol? In a function? In an ERT test? On a lambda? The menu items added by Anju take these factors into account to provide a relevant menu offering.

Users can read more about Anju’s context menu enhancements for Elisp development at Emacs Lisp Context Menu (Anju User Guide).

Some backstory with Edebug

Back in 2024, I did a deep dive into Edebug so as to give a presentation on it at the EmacsSF meetup. In doing so, I realized that all the core features for having an Elisp IDE were there, but no good UI to present it. I set upon prototyping one using Transient, with decidedly mixed results due to both Edebug and Transient fighting each other over window management.

A later Edebug UI prototype using the toolbar was attempted but it also had its issues, particularly with layout (or lack thereof) and toolbar-specific bugs in macOS. But a benefit of using the toolbar was that its UI interactions did not interfere with window management. The context menu also shares this benefit.

Closing Thoughts

The context menu has markedly improved my developer experience with Elisp, as I find myself using it more than typing out keybindings. Even with keybindings, I’ll use the Casual Elisp Transient to accomplish most Elisp interactions that don’t require Edebug.

That said, I’m not here to eschew keybindings. I still use them, when convenient. But in many circumstances they are not. The context menu can provide an easier way to achieve the same thing. Isn’t that a good thing?

Bulk Search & Replace Commands for Files and Buffers in Emacs

2026-04-29T22:15:00-07:00

Emacs offers a dizzying number of commands to perform bulk operations on multiple files or buffers. These commands are quite capable and can make trivial the execution of workflows that would be heroic in other editors. Unfortunately these commands are also difficult to discover as a number of them are not featured in easily accessible menus.

This post calls attention to bulk commands related to search and replace in Emacs and how their discoverability can be improved using the Casual and Anju UI packages.

Regular Expressions

Before moving forward, let’s talk about how Emacs handles regular expression syntax in search and/or replace commands. Whenever using an Emacs command involving a regular expression (regexp), you will need to understand what kind of regexp syntax is expected. There are largely two to know:

Emacs
grep (implementation dependent)

Commands using grep-style regexps do so because they invoke the local install of the grep utility. The grep regex syntax is implementation dependent. If you use GNU grep, you can read its syntax here, which share some character classes with Emacs.

The Casual RE-Builder package is a great way to work with Emacs regexps as it provides a command to escape the regexp properly for interactive input. re-builder alone only provides a regexp that can be used in Elisp code.

Bulk Search & Replace Commands

The table below shows the different search and/or replace workflows and their associated commands.

Workflows	Command	Regexp Type	Notes
Search regexp in files in directory	rgrep	grep	AKA “Find in Files.” Results can be edited using writeable grep (wgrep).
Search regexp in files in project	project-find-regexp	grep
Search regexp in files in directory and present in Dired	find-grep-dired	grep
Search regexp in tagged files	tags-search	Emacs
Search file names matching shell pattern in directory and present in Dired	find-name-dired	shell
Search file names matching regexp in directory and present in Dired	find-lisp-find-dired	Emacs	Implementation uses Emacs regexp type.
Search file names matching regexp in current directory and present in Dired	casual-dired-find-dired-regexp	Emacs	Wrapper around find-lisp-find-dired using current directory. Available via Casual.
Query replace regexp in project files	project-query-replace-regexp	Emacs
Incremental search marked files with plain text	dired-do-isearch		For use in Dired.
Incremental search marked files with regexp	dired-do-isearch-regexp	Emacs	For use in Dired.
Query replace regexp in marked files	dired-do-query-replace-regexp	Emacs	For use in Dired.
Search regexp in marked files	dired-do-find-regexp	grep	For use in Dired.
Search regexp in marked files and display first match	dired-do-search	Emacs	For use in Dired.
Replace regexp in marked files	dired-do-find-regexp-and-replace	grep	For use in Dired.
Replace regexp in marked files using diff interface.	dired-do-replace-regexp-as-diff	Emacs	For use in Dired.
Incremental search marked buffers with plain text	ibuffer-do-isearch		For use in IBuffer.
Incremental search marked buffers with plain text with regexp	ibuffer-do-isearch-regexp	Emacs	For use in IBuffer.
View lines which match regexp in marked buffers	ibuffer-do-occur	Emacs	For use in IBuffer.
Query replace plain text in marked buffers	ibuffer-do-query-replace		For use in IBuffer.
Query replace regexp in marked buffers	ibuffer-do-query-replace-regexp	Emacs	For use in IBuffer.
Run git grep, searching for regexp in directory.	vc-git-grep	grep
Replace all references to identifier.	xref-find-references-and-replace
Interactively replace identifier in current xref buffer.	xref-query-replace-in-results
Rename symbol at point for project.	eglot-rename		Requires Eglot support.
Replace regexp in files using diff interface.	multi-file-replace-regexp-as-diff	Emacs
Start multi-buffer incremental search on a list of files.	multi-isearch-files
Start multi-buffer incremental regexp search on a list of files.	multi-isearch-files-regexp	Emacs
Start multi-buffer incremental search on a list of buffers.	multi-isearch-buffers
Start multi-buffer incremental regexp search on a list of buffers.	multi-isearch-buffers-regexp	Emacs
Show all lines in buffers containing a match for regexp.	multi-occur	Emacs
Show all lines containing a match for regexp in buffers that match bufregexp.	multi-occur-in-matching-buffers	Emacs

Choice of command depends on the quantity and specificity of files or buffers to work on. Both Dired and IBuffer marking allow for specific selection of files or buffers respectively.

Many of the commands in the table above are discoverable via menu using the Casual and Anju packages. Hierarchical menu categorization aids in the discovery and recognition of these commands, making them more usable.

Command	UI	Notes
rgrep	(C-o) casual-editkit-main-tmenu › (/) Search/Replace › (g) Find in Files…	Available via Casual EditKit.
rgrep	(Menu-bar) Edit › Search › Search in Files…	Available via Anju.
project-find-regexp	(Menu-bar) Edit › Search › Search in Project Files…
tags-search	(Menu-bar) Edit › Search › Search Tagged Files…
project-query-replace-regexp	(Menu-bar) Edit › Replace › Replace in Project Files…
find-name-dired	(C-o) casual-editkit-main-tmenu › (/) Search/Replace › (d) Files…	Available via Casual EditKit.
find-grep-dired	(C-o) casual-editkit-main-tmenu › (/) Search/Replace › (G) Files containing text…	Available via Casual EditKit.
casual-dired-find-dired-regexp	(C-o) casual-dired-tmenu › (f) Filter by name…	Available via Casual Dired.
dired-do-isearch	(C-o) casual-dired-tmenu › (/) Search/Replace › (C-s) I-search…	Available via Casual Dired.
dired-do-isearch-regexp	(C-o) casual-dired-tmenu › (/) Search/Replace › (M-s) I-search regexp…	Available via Casual Dired.
dired-do-query-replace-regexp	(C-o) casual-dired-tmenu › (/) Search/Replace › (r) Query regexp and replace…	Available via Casual Dired.
dired-do-find-regexp	(C-o) casual-dired-tmenu › (/) Search/Replace › (g) Find regex…	Available via Casual Dired.
dired-do-search	(C-o) casual-dired-tmenu › (/) Search/Replace › (s) Search first regexp match…	Available via Casual Dired.
dired-do-find-regexp-and-replace	(C-o) casual-dired-tmenu › (/) Search/Replace › (G) Find regex and replace…	Available via Casual Dired.
ibuffer-do-isearch	(C-o) casual-ibuffer-tmenu › (C-s) I-Search…	Available via Casual IBuffer.
ibuffer-do-isearch-regexp	(C-o) casual-ibuffer-tmenu › (C-M-s) I-Search Regexp…	Available via Casual IBuffer.
ibuffer-do-occur	(C-o) casual-ibuffer-tmenu › (O) Occur…	Available via Casual IBuffer.
ibuffer-do-query-replace	(C-o) casual-ibuffer-tmenu › (M-r) Query Replace…	Available via Casual IBuffer.
ibuffer-do-query-replace-regexp	(C-o) casual-ibuffer-tmenu › (C-M-r) Query Replace Regexp…	Available via Casual IBuffer.
vc-git-grep	(Menu-bar) Tools › Version Control > Git grep…

Refactoring Guidance

The replace commands can do catastrophic damage if not used with caution. Treat them like power tools.

Some guidance before using replace commands:

Have a backup plan in case you need to recover anything.
Use re-builder to help figure out the right regexp.
Know the scope of what you want to change (directory, files, buffers).
Some commands will only modify the buffer of an affected file. Check if modified buffers are saved. You can use IBuffer to identify and save such buffers. It is left as an exercise to the reader to determine which commands exhibit this behavior.

Closing Thoughts

The inventory of commands above are from what I know of Emacs, which is guaranteed to not be comprehensive. If there are others missing from this list, please let me know at kickingvegas@gmail.com.

While many of these commands have been in Emacs for years (decades even), they were not usable to me until I built a UI for them. I think motivated readers using Casual and Anju for bulk search and/or replace tasks will find a similar sentiment.

Amended 2026-04-30: Added vc-git-grep, eglot-rename, xref-find-references-and-replace, and xref-query-replace-in-results. Thanks to Henry Leach and Gene Pasquet for their input!

Amended 2026-05-04: Added dired-do-replace-regexp-as-diff, multi-file-replace-regexp-as-diff, multi-isearch-files, multi-isearch-files-regexp, multi-isearch-buffers, multi-isearch-buffers-regexp, multi-occur, multi-occur-in-matching-buffers. Learned about the diff commands from Christian Tietze's post Preview Mass Text Replacements with Emacs 30.1 replace-regexp-as-diff.

Some nice to know keybindings when using the mouse in Emacs

2026-04-24T13:40:00-07:00

These keybindings are good to know when working with a mouse in Emacs.

F10 (menu-bar-open) :: Start key navigation of the menu bar in FRAME.

S-F10 (context-menu-open) :: Start key navigation of the context menu. This needs context-menu-mode enabled.

C-M-mouse-1 :: Activate a rectangular region around the text selected by dragging. Useful for rectangle operations.

M-Drag-mouse-1 :: Set the secondary selection, with one end at the place where you press down the button, and the other end at the place where you release it. See Secondary Selection for more info.

C-mouse-3:: Raise menu populated with the menu mode map of the current mode and if Imenu is enabled, an index menu for that buffer.

C-u n (optional) :: A prefix argument can be passed to a menu item.

Keyboard Macro :: Commands issued via menu can be used when recording a keyboard macro. (🤯 Who knew?)

C-x z (repeat) :: Repeat most recently executed command. Yes, repeat works also for commands issued via mouse too!

Knowing that repeat works with menu commands (both main and context) is particularly useful with the additions to the main menu made by the latest Anju v1.2.0 update. Shown below is a demo of using “Duplicate” (duplicate-dwim) from the Edit menu, then using C-x z and then z successively to repeat the duplication.

Your browser does not support HTML video. Link to video.

Amended 2026-04-25: Added C-M-mouse-1, M-Drag-mouse-1, C-mouse-3, C-u n, Keyboard Macro items.

Call for Testing: Scrim v1.1.3 TestFlight on pre-release Emacs 31

2026-04-23T14:40:00-07:00

For folks who like using the development build of Emacs (at the time of this writing Emacs 31.0.5) on macOS, it turns out there is a bug in how Scrim sends Org protocol requests to it.

A fix has been identified and so far it works fine for both Emacs 30.2 and 31.0.5 from my testing. That said, it is always better to have more folks trying it out.

If you use the latest Emacs 31.0.5+ on macOS and use (or are interested in using) Org protocol, I invite you to try out a TestFlight build of Scrim v1.1.3.

If this is the first time you’ve heard about Scrim, learn more about it at http://yummymelon.com/scrim/

Thanks much!

Computing Days Until with Emacs

2026-04-08T16:00:00-07:00

A recent Mastodon post showing the days until the next U.S. election got me to wonder, “how can I compute that in Emacs?” Turns out, this is trivial with the Org mode function org-time-stamp-to-now doing the timestamp computation for you.

We can wrap org-time-stamp-to-now in an internal function cc/--days-until that generates a formatted string of the days until a target date.

(defun cc/--days-until (target &optional template)
  "Formatted string of days until TARGET.

- TARGET: date string that conforms to `parse-time-string'.
- TEMPLATE : format string that includes ‘%d’ specifier.

If TEMPLATE is nil, then a predefined format string will be
used."
  (let* ((template (if template
                       template
                     (concat "%d days until " target)))
         (days (org-time-stamp-to-now target))
         (msg (format template days)))
    msg))

From there we can then start defining commands that use cc/--days-until. The command cc/days-until shown below will prompt you with a date picker to enter a date. Note that you can enter a date value (e.g. “Dec 25, 2026”) in the mini-buffer prompt for org-read-date.

(defun cc/days-until (arg)
  "Prompt user for date and show days until in the mini-buffer.

Use `org-read-date' to compute days until to display in the mini-buffer.

If prefix ARG is non-nil, then the computed result is stored in the
 `kill-ring'."
  (interactive "P")
  (let* ((target (org-read-date))
         (msg (cc/--days-until target)))
    (if arg
        (kill-new msg))
    (message msg)))

Going back to the original motivator for this post, here’s an implementation of days until the next two major U.S. election dates with the command cc/days-until-voting.

(defun cc/days-until-voting (arg)
  "Days until U.S. elections in 2026 and 2028.

If prefix ARG is non-nil, then the computed result is stored in the
 `kill-ring'."
  (interactive "P")
  (let* ((midterms (cc/--days-until "2026-11-03" "%d days until 2026 midterms"))
         (election (cc/--days-until "2028-11-07" "%d days until 2028 presidential election"))
         (msg (format "%s, %s" midterms election)))
    (if arg
        (kill-new msg))
    (message msg)))

The result of M-x cc/days-until-voting as of 8 April 2026 is:

209 days until 2026 midterms, 944 days until 2028 presidential election

It’s so human to want to know how long it’s going to take. Feel free to build your own countdown clocks using the code above. May your journey to whatever you plan be a happy one!

notes from /dev/null - emacs

Announcing shazam.el

Background

Implementation

Features

Closing Thoughts

References

Simplifying Setup for Casual

Bumping to 3.0

Announcing now-playing.el, an Emacs interface for the macOS Music app

Closing Thoughts

Malleable Computing, Emacs, and You

Requirements

Specification

Implementation

Malleable Computing Observations

Software Scope - Some Percentage Anecdotes

Build for 1 or N

Malleable Software and User Agency

Closing Thoughts

Links

Addendum 2026-07-23 11:30 PST

In Emacs, Everything Looks Like a Service

Client-Server Model

Emacs as a Client

Elisp

Example wttr.in client

Closing Thoughts

Scheduling Future Tasks in Emacs

Example: Scheduling a macOS Notification

Closing Thoughts

Revisiting Emacs Keyboard Macros with a Mouse

Opening macOS Finder Folders in Emacs with Scrim

TL;DR

Motivation

Background

Scrim

Services

“Open in Emacs” Shortcut

“scrim link” Shortcut

Closing Thoughts

Anju v1.5.0 Update

Using the Mouse for Emacs Rectangle Commands

Enhancing Elisp Development with Context Menus

Some backstory with Edebug

Closing Thoughts

Bulk Search & Replace Commands for Files and Buffers in Emacs

Regular Expressions

Bulk Search & Replace Commands

Refactoring Guidance

Closing Thoughts

Some nice to know keybindings when using the mouse in Emacs

Call for Testing: Scrim v1.1.3 TestFlight on pre-release Emacs 31

Computing Days Until with Emacs