nfdn: In Emacs, Everything Looks Like a Service
notes from /dev/null
by Charles Choi 최민수
In Emacs, Everything Looks Like a Service
09 Jul 2026 Charles Choi
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
Minibuffers
Buffers
Completion
Tabulated List Mode
Variable Pitch Table (vtable)
Transient
Client Edge
URL
Socket (TCP/UDP)
SMTP
Serialization/Deserialization<br>JSON
XML
Local Database
Collections<br>Association Lists
Property Lists
Hash Tables
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.
10<br>11<br>12<br>13<br>14<br>(defun wttr (location)<br>"Show weather conditions for LOCATION from `https://wttr.in' in mini-buffer.
Result is also stored in `kill-ring'."<br>(interactive "sWhere (default: local): ")
(condition-case err<br>(let* ((url (wttr--request-url location))<br>(jsondb (fetch-json-as-hash-table url))<br>(msg (wttr--report-message jsondb)))<br>(kill-new msg)<br>(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)<br>"Construct wttr.in URL with LOCATION."<br>(let* ((base-url (url-generic-parse-url "https://wttr.in"))<br>(encoded-location (string-replace " " "+" location))<br>(query (format "/%s?0&format=j1" encoded-location))<br>(_dummy (setf (url-filename base-url) query)))<br>(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.
10<br>11<br>12<br>13<br>(defun fetch-json-as-hash-table (url)<br>"Fetch URL with expected JSON response and return a `hash-table'."<br>(let ((data-buffer (url-retrieve-synchronously url)))<br>(if (not data-buffer)<br>(error "Failed to fetch data from %s" url)<br>(unwind-protect<br>(with-current-buffer data-buffer<br>;; Move point past the HTTP metadata headers<br>(goto-char url-http-end-of-headers)<br>;; Parse the remaining JSON buffer into a hash-table<br>(json-parse-buffer :object-type...