Show HN: I forced Claude to play Tetris in Emacs(imgur.com)
imgur.com
Show HN: I forced Claude to play Tetris in Emacs
https://imgur.com/a/e3nxq5k
4 comments
I have Lisp REPL loops that operate on multiple levels:
- On Mac, my [Hammerspon config is in Fennel](https://github.com/agzam/spacehammer) and exposes an nrepl endpoint - I can directly inspect any UI element of any app. [Here I'm picking from visible threads from Slack App](https://imgur.com/a/1lsmejB) to open them in Emacs. I would never have done that without an LLM - not even a skill issue, it's just a bunch of tedious, manual precision calculations - LLM inspects the UI elements and grabs even the avatars to show them `hs.chooser` UI.
- On Linux I have a [babashka](https://github.com/babashka/babashka) script that talks to the Hyprland compositor - I can inspect and conditionally move windows around, change display color temp, etc.
- On my team we have several services written in Clojure, on SDEs and staging we exposed nrepl ports - we can dynamically change things running in k8s pods.
- It all gets controlled from my "operational theater" - Emacs. Not only I can change any behavior of the editor itself on the fly, I can change any aspect of my local and remote systems dynamically.
This was all possible even before the LLMs. Now with AI, it's weirdly horrifying but enormously fun at the same time. I just don't understand why the majority still ignores Lisp - this is exactly the time when a PL syntax may no longer matter much anymore, but the super feature of real REPL that gives a pragmatic, incontestable edge can make a huge difference. On top of that - it was already proven that Lisp dialects are more token-efficient. I believe that, because I know first-hand how terse yet immensely effective Lisp code can be - all without getting bogged down to the cryptic level of APL.
- On Mac, my [Hammerspon config is in Fennel](https://github.com/agzam/spacehammer) and exposes an nrepl endpoint - I can directly inspect any UI element of any app. [Here I'm picking from visible threads from Slack App](https://imgur.com/a/1lsmejB) to open them in Emacs. I would never have done that without an LLM - not even a skill issue, it's just a bunch of tedious, manual precision calculations - LLM inspects the UI elements and grabs even the avatars to show them `hs.chooser` UI.
- On Linux I have a [babashka](https://github.com/babashka/babashka) script that talks to the Hyprland compositor - I can inspect and conditionally move windows around, change display color temp, etc.
- On my team we have several services written in Clojure, on SDEs and staging we exposed nrepl ports - we can dynamically change things running in k8s pods.
- It all gets controlled from my "operational theater" - Emacs. Not only I can change any behavior of the editor itself on the fly, I can change any aspect of my local and remote systems dynamically.
This was all possible even before the LLMs. Now with AI, it's weirdly horrifying but enormously fun at the same time. I just don't understand why the majority still ignores Lisp - this is exactly the time when a PL syntax may no longer matter much anymore, but the super feature of real REPL that gives a pragmatic, incontestable edge can make a huge difference. On top of that - it was already proven that Lisp dialects are more token-efficient. I believe that, because I know first-hand how terse yet immensely effective Lisp code can be - all without getting bogged down to the cryptic level of APL.
Your GitHub link 404s.
I wonder, why not just get ECA to run `emacsclient -e <elisp>` instead? Does that not work as well?
I wonder, why not just get ECA to run `emacsclient -e <elisp>` instead? Does that not work as well?
Thank, you, I did't realize I forgot to make the repo public. Fixed it.
Why MCP? `emacsclient -e` is the transport. The MCP is the transport plus quoting, output capture, error handling, timeouts, inline hints, screenshots, and tool-schema discoverability. You can reimplement all of that inside every LLM turn, but you pay for it in tokens, latency, and bug surface on every call. The MCP lifts that boilerplate out of the conversation once and never charges you for it again.
Why MCP? `emacsclient -e` is the transport. The MCP is the transport plus quoting, output capture, error handling, timeouts, inline hints, screenshots, and tool-schema discoverability. You can reimplement all of that inside every LLM turn, but you pay for it in tokens, latency, and bug surface on every call. The MCP lifts that boilerplate out of the conversation once and never charges you for it again.
AI hands it a string of Lisp, it runs inside live Emacs session, poking into it via emacsclient. Behaves like a REPL the LLM can drive - state persists between the calls.
Emacs is a Lisp machine. Buffers, files, network, subprocesses, games, major modes, the UI itself: every feature is already an elisp function. Hand an LLM a way to run arbitrary elisp and it inherits the entire Emacs API for free. No per-task glue code required.
The same MCP can drive Magit, Org, Eshell, Dired, eww, or anything else someone ever wrote in elisp. Tetris is just to make the point.