This is wonderful. Consider decoupling the core from Emacs, or packaging in a way that doesn’t require it as heavily.

I’ve been doing my own exploration of terminal ASCII games via Dwarf Fortress instead of SimCity. I’ve learned that letting a coding agent play is an interesting way to get feedback as well :)

https://github.com/brimtown/claude-fortress

I tried something similar with a roguelike I was prototyping last year. Ended up being more useful for finding edge cases than actual gameplay feedback - the agent would do things no human would ever try, like walking into walls repeatedly or hoarding useless items. Still caught a bunch of bugs I never would have found otherwise.

> Consider decoupling the core from Emacs, or packaging in a way that doesn’t require it as heavily.

but then we'd have to write an interface package to run it from emacs

How would it be run without Emacs?

You might point out that there are things like elisp.lisp that purports to run Emacs Lisp in Common Lisp, but I'm not sure that's viable for anything but trivial programs. There's also something for Guile, but I remain unconvinced.

Maybe a Common Lisp core with an Emacs frontend running it in https://www.gnu.org/software/emacs/manual/html_mono/cl.html?

Why not just use the best known emacs lisp core, then? Like say emacs.

To allow it to run on other lisp dialects as well.

(I’m just trying to defend GP’s point – I’m not a heavy lisp user myself, tbh.)

Portability across Lisp dialects is usually not a thing. Even Emacs Lisp and Common Lisp which are arguably pretty close rarely if ever share code.

You could make a frontend for dialect A to run code from dialect B. Those things have been toyed with, but never really took off. E.g. cl in Emacs can not accept real Common Lisp code.

I'm not arguing against the idea, I'm just curious how it would work because I see no realistic way to do it.

Gotcha. Too bad – I was hoping there was at least some (non-trivial) subset you can run on both :(

Any idea why is it not a thing? Is this level of interop not practical for some reason?

Lisp dialects have diverged quite a bit, and it would be a lot of work to bridge the differences to a degree approaching 100%. 90% is easy, but only works for small trivial programs.

I say this, having written a "95%" Common Lisp for Emacs (still a toy), and successfully ran an old Maclisp compiler and assembler in Common Lisp.

https://github.com/larsbrinkhoff/emacs-cl

https://github.com/PDP-6/ITS-138/blob/master/tools/maclisp.l...

still in their main doc https://www.gnu.org/software/guile/manual/html_node/Emacs-Li...

Having read that, I'm even less convinced it's not more than a toy.

you could probably use the unexec tooling

I don't see how unexec would help with "decoupling the core from Emacs" since the core is written in Emacs Lisp.

you could make a standalone executable. I was assuming that people didn't want to start emacs to run it. if its just because...emacs is just morally offensive and one doesn't even want it running under the covers, I dont how to help you.

Emacs is needed because it provides Emacs Lisp.

If you used Emacs as a stand-alone game engine, at least it could make it claim it was "Reticulating Splines..." for a few minutes while it started up.

I kid, I kid! I love Emacs. I named my cat Emacs!

I mean, i dont mind it but having a client/server architecture is a very different story to just 2 elisp modules.

Here, the point was to have everything in emacs completely, and also see if the architectural contraints make sense for elisp (and they do)

And have some fun, of course.

“standardize the intersection, expose the union” is a great phrase I hadn’t heard articulated before

I've got the wording from an llm. I knew there was this pattern in all traditional tools - but I did not know the name.

You’ve never heard it before because explicitly signaling “I know basic set theory” is kind of cringy

I’m currently letting Claude build and play its own Dwarf Fortress clone, as an installable plugin in Claude Code

https://github.com/brimtown/claude-fortress

There is a PermissionRequest hook [1], along with Notification

https://code.claude.com/docs/en/hooks-guide#hook-events-over...

It must be newer because Opus never seems to know about it, and the claude-code-guide tool that fires occasionally misses it

This is @simonw’s Lethal Trifecta [1] again - access to private data and untrusted input are arguably the purpose of enterprise agents, so any external communication is unsafe. Markdown images are just the ones people usually forget about

[1] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

Good point around the markdown image as an untrusted vector. Lethal trifecta is determnistically preventable, it really should be addressed wider in the indutry

I have a soft spot for these JS fuzzy matchers, but there are so many that it’s worth talking about about the specific tradeoffs you chose / ideally offering an interactive comparison like μFuzzy does:

https://github.com/leeoniya/uFuzzy

μFuzzy has a great comparison project that could serve as a reference for all fuzzy search implementations. My fuzzy searcher (v1) is already included and will soon be updated to v2 (PR is open).

i will caveat that the demo really only tests a specific set of options for each lib that try to closely match what uFuzzy does; and you can only adjust uFuzzy options in the ui. so do your own testing :)

Had hoped to see Neural Cellular Automata [1] mentioned as an extension of continuous, learnable automata.

[1] https://distill.pub/2020/growing-ca/

I work in this building - it’s a wonderful experience walking through it every morning, and will be sad to see it go!

You might be interested in https://www.datadoghq.com/blog/engineering/computing-accurat...

Disclaimer: I work there/built the TypeScript implementation of the library

See also https://github.com/Munter/subfont#readme (or https://www.gatsbyjs.org/packages/gatsby-plugin-subfont/ for Gatsby sites).