[iLemming]

> LLMs have inspired a similar change in me

FWIW, the age of LLMs made me build a deeper, more intimate relationship with Emacs, because it's a Lisp REPL loop with a built-in editor, not the other way around. When you give an LLM a closed loop system where it can evaluate code in a live REPL and observe the results, it stops guessing and starts reasoning empirically.

LLM that I run inside Emacs can fully control the active Emacs instance. I can make it change virtually any aspect of it. To load-test things, I even made it play Tetris in Emacs. And not just simply run it, but to actually play it without losing. It was insane.

Also, Emacs is all about plain text - you can easily extract text from anything - from the browser, terminal, CLI apps, Slack, Jira, etc., and you can do that on your own terms - context can appear in a buffer, in your clipboard, become a file or series of API requests. That is really hard to beat.

[minikomi]

Asolutely. It doesn't have to be an either-or. I use gptel and org mode when I was to be really hands on driving the development. It's a very different mode of interacting with models, and the way newer models are trained to play nice with harnesses makes them very obedient.

https://poyo.co/note/20260202T150723/

[mncharity]

Interesting. Tnx.

In case anyone else wondered about using gptel to edit thinking (eg vis Qwen3.6's `preserve thinking`), [1] explains:

> In a multi-turn request, from the time you run `gptel-send`, everything the LLM sends is passed back to it [...during tool calls...] includes multiple reasoning blocks. [...But...] subsequent gptel-send calls read their input from the buffer contents (or active region, etc), so the reasoning blocks in the buffer will not [] be sent as "reasoning_content".

But in org mode, those are apparently `#+being_reasoning` blocks (`gptel-include-reasoning`?), so editable thought might be an easy addition?

A caution, fwiw, that any llms which respond with interleaved content and reasoning blocks, currently only work when not streaming, and fixing that is non-trivial.[also 1]

[1] https://github.com/karthink/gptel/issues/1282

[kqr]

Is this your site? I cannot find an RSS feed for it. I'd like to subscribe.

[minikomi]

Cheers mate I added one at https://poyo.co/feed.xml

[mark_l_watson]

Same for me!

My .emacs config has improved and I wrote my own Emacs based coding agent https://github.com/mark-watson/coding-agent

[ww520]

Same here. Emacs has been the stable editor for all kinds of language changes, tool changes, and IDE changes. Emacs is great with LLM, as LLM is mostly text related and Emacs is great in capturing and dealing with text.

[mimischi]

Can you describe your setup on how you use LLMs within Emacs?

[iLemming]

Of course.

I've tried different AI packages and currently gptel and ECA remain the main ingredients. This is a quickly changing landscape, and things may change, but for now it feels very good.

I like gptel because it's enormously extendable and exploitable - it allows me to send LLM requests from just about anywhere - I could be typing a message (like this very one) and suddenly in need of ideas for how to phrase something better, or explain simply, or fact-check my assumptions, whatever. Quick & dirty interaction that gets discarded in the same buffer. For longer investigations and research I would use a dedicated gptel buffer. Those get automatically saved.

I don't use gptel as a coding assistant, even though you can do that, it's not really optimized for that kind of work. I use ECA. It works much better for me than every other alternative I tried, and I tried more than a few. What's crazy that I sometimes would type a prompt in ECA, then ask gptel (with a different model) to make it more "AI-friendly" changing the prompt in-place and then send it.

All my MCPs are coded in Clojure (mostly babashka)¹ - because (like I said) giving an AI a Lisp REPL makes much more sense (maybe even more than using a statically typed language). I had to employ a few tricks so all the tools, skills and instructions can be shared between gptel, eca-emacs, ECA Desktop, Claude Code CLI, Claude Desktop App, and Copilot CLI. Even though I mostly use gptel and ECA, it's good to keep other options around, just in case. All the AI-related Emacs settings are in my config².

Is this helpful, or you want some more concrete examples?

—

¹ https://github.com/agzam/death-contraptions

² https://github.com/agzam/.doom.d/tree/main/modules/custom/ai

[zingar]

I’d like a concrete example on how you’re actually controlling emacs with LLMs. Is ECA the part that does that?

[iLemming]

gptel has the built-in elisp eval tool. ECA doesn't have it built-in, I use my custom MCP (I posted the link in the comment above).

[pandakar]

This is good stuff :) Honestly, I am having a lot of fun just using org mode files as prompts and eventually output for a Claude Code instance in vterm. All these files get saved with the output and magit is of course amazing, just good affordances and history keeping.

[iLemming]

(setopt gptel-default-mode 'org-mode)

For persistence:

https://github.com/agzam/.doom.d/blob/main/modules/custom/ai...

[spudlyo]

I am really loving working on a fun Elisp project with pi, a minimal and very extensible agent. I have the agent use emacsclient to control my session, showing me code, running magit ediff for me, testing, formatting, reloading -- it's all working great.

I'm still exploring all the ways the agent and I can collaborate using Emacs as a shared medium, but at the moment am super optimistic about it.

[0x20cowboy]

So much this. Lisp can do things other languages have a hard time with. I think a resurgence is in order.

[iLemming]

Can't agree more. Lisp was discovered/invented for the purpose of AI research. Of course, modern neural nets and transformers is a big departure from McCarthy's vision of AI - logical, interpretable, symbolic. However, if the current wave of AI hits a wall - and many serious researchers think it will, or already has at the margins - there's growing interest in neurosymbolic approaches that combine neural nets with symbolic reasoning. That's closer to McCarthy's original vision, and Lisps are genuinely well-suited for it.

Let's be honest: Lisp probably won't ever get bigger than Python, unless Python for whatever reason starts dying on its own. But if AI ever gets serious about interpretability, formal reasoning, program synthesis - all the stuff Lisp was built for - it just might quietly become relevant again in research contexts, without ever reclaiming mainstream status.

Scicloj has been building out a serious ML stack in Clojure - noj, metamorph.ml, scicloj.ml.tribuo, libpython-clj for Python interop. Beside that, people been proving that 'code is data' is exactly what makes it a better target for LLMs. Clojure is most token efficient PL - it's been proven. There are some recent interesting clj projects in relevance:

—

https://github.com/realgenekim/clj-surgeon

https://clojure.getpando.ai

https://github.com/yogthos/chiasmus

[piokoch]

Well, this is because "normal" programming languages are one step above AST. So LLM has to work with program text, which is much easier than regular human text, as it is constrained to well defined number of keywords and grammar, but still this is pretty variable. Lisp is just AST, so it is one level lower. I guess that at some point LLM-s will stop writing human-readable code, as this is additional obstacle, they will work directly with binaries or virtual machines code (like in Java), because this will be easier and eat less tokens.

[iLemming]

> LLM-s will stop writing human-readable code, as this is additional obstacle, they will work directly with binaries

LLMs already internally operate on embeddings - dense floating-point vectors in high-dimensional space - they don't need "intermediary language" - there's no discrete symbolic reasoning - it's continuous numerical computation all the way through.

If you made an LLM to generate bytecode, you'd need it to "read" bytecode tokens as context for predicting the next bytecode token. The model would need to have learned the statistical patterns of bytecode sequences, which are far less structured and too arbitrary than (human readable) source code. Bytecode is optimized for machine execution, not for having patterns for a next-token predictor.

So Lisp actually is the sweet spot in the direction you're gesturing at, but you got the direction backwards. You don't want to go lower (toward bytecode), you want to go toward representations that have: fewer syntactic rules, structural, and high in local predictability. That is basically Lisp. The AST is the syntax. There's no parsing ambiguity, minimal syntactic variation, and the structure is self-describing. The model spends fewer tokens on syntactic ceremony and more on semantic content. That is why LLMs are surprisingly great at generating Elisp and Clojure code.

[anthk]

Clojure? Forget it, SBCL would be better for that task. Just look what could be done with Coalton.

[iLemming]

"Technically superior in isolation" argument, unfortunately (as relatively short history of our field shows) rarely manifests in tools being actively used by many. Coalton's type system is absolutely more powerful than what Clojure offers. But language choice in production is dominated by libs, hiring, tooling, and operational maturity - Clojure wins all of those handily. Unfortunately, the same argument can be made about Clojure and... I dunno, Python. Clojure occupies a middle, nicely defensible ground.

SBCL is a fine choice for a solo project or research; recommending it over Clojure for a team/production setting though requires ignoring most of what actually matters. Every language stack choice is a bet on where the tradeoff between power and pragmatism pays off for your specific context. Clojure's bet is a more conservative than CLs, yet both may seem (for some) more aggressive bets than just using Python. It all depends on the team.

[devin]

Big same. I have been doing a lot of clojure development, and hooking up my app to a live REPL has given me an absolutely fantastic feedback loop for the LLM. I don't think a lot of people understand what they're missing.

[iLemming]

> I don't think a lot of people understand what they're missing

Very true. There's an enormous tacit knowledge gap. Check this out:

I have to use Mac for work. My WM is Yabai, which is controlled via Hammerspoon (great tool on its own), which means I can use Fennel, which means I can have a Lisp REPL. MCP connected to that REPL can query and inspect every single window I have on my screen. It can move them around, it can resize them, it can extract some properties of them. It's figuring out stuff like: "pick a selected Slack thread from the app and send it into an Emacs buffer", or "make my app windows work like Emacs buffers" - pick from the list and swap it in place. Or "find the HN thread about retiring from Emacs among my browser tabs and summarize the content"...

Never in my life have I been more grateful to my younger self for grokking the philosophy of Lisp. Recent months have only reinforced my firm belief that this 70-year-old tech is truly everlasting. Thank you, John McCarthy, for the great gift to humanity, even though so weirdly underappreciated.

[iLemming]

Ah, that's on Mac, but I forgot to tell you about the Linux. On Linux, I ran my modal-keyboard-toolkit controlled through babashka (clojure) with an exposed nREPL endpoint. That means I can query and control windows - their placement, change brightness and color temp. - all interactively, directly from my editor. I can write some conditional event loop, e.g., time-based color temp changes. Because I have a Lisp REPL - I can test out all the colors, squeezing the entire day into a minute - simulate, eval and preview the results - no saving, no reloading, no recompilation. Once satisfied - I can put the time markers accordingly - so colors change depending on the time of day.

[uint32_t]

This is very interesting! I've played around with Hammerspoon for a bit but nowhere near this level. Do you have a link to your config or could you give me a bit more detail on your setup?

[iLemming]

https://github.com/agzam/spacehammer

https://github.com/agzam/.spacehammer

[iLemming]

Note, these are two different repos. One is the toolkit, the other is my custom config on top of it.

[imoverclocked]

> LLM that I run inside Emacs can fully control the active Emacs instance ... > you can easily extract text from anything

This is what gives me the most pause.

[iLemming]

Care to explain? Why is it? You think it's dangerous or some other reasons?

[imoverclocked]

It's definitely dangerous.

Do you have credentials anywhere within reach of that session? Can you open your bank account in a browser ... within reach of that session? Are your contacts available within reach of that session? What about personal notes/emails/goals or other sensitive information? That people think these can't be added together in one very socially/monetarily destructive fell swoop is ... telling.

Ignoring obvious bad-actor concerns from just giving root to your whole life to an LLM running on someone else's server, LLMs themselves can act in ways that are extremely counterproductive to their organization/host/etc.

A quote/warning I learned in the late 90s is just as relevant today, "Computers make very fast, very accurate mistakes."

[Blackthorn]

Emacs has full system access with arbitrary execution so full emacs access -> full system access.

[arikrahman]

The RCE vulnerabilities especially with community flavors of Emacs that come with access control out of the box.

[SoftTalker]

What? You run emacs as root?

Anything an LLM does on your computer should happen it its own account. No sudo config of course, or at most one that is strictly limited to what you want to allow it to do (risk here, as many programs have non-obvious paths to general command execution).

It should have zero access to your private home directory or your system configs. You can have access to its files of course. That's the beauty of separate accounts and permissions.

[i_think_so]

How many devs really do run damned near everything from a single account that also has sudo/runas/various_osx_methods access? This threat model has a decidedly non-zero target market.

Even those folks who are cautious enough to require passwords (sudo or plain su) to elevate are still at risk of having their account thoroughly brought under control of an attacker. Just imagine what a baddie could inject into your .bashrc if your editor can change it.

If you run your clanker-controlled emacs in console mode under a restricted user account, best case scenario, system compromise is only one unpatched privesc vuln away from Shai-Hulud completely pwning you.

Doing it in a locked down VM is much better but even then you're only better off by matter of degrees than if you had done a yolo curl - | bash because VM host attacks and even escapes are very much a thing.

These HNers expressing concern about giving a LLM control of an editor are 100% thinking rightly.

[iLemming]

This is a textbook motte-and-bailey. You're telescoping threat escalation - chaining together "what if" steps until everything sounds equally catastrophic:

"Your editor can write to .bashrc. Therefore an attacker controls your shell. You probably have sudo. Therefore full system compromise. Even a VM does not help because VM escapes exist. Therefore this is basically curl|bash."

By this reasoning, every program you run under your user account is equally dangerous. Your shell, your file manager, git, make, pip install, npm install, docker, any program that writes files. The argument proves too much, therefore proves nothing.

This is all unhinged poetry - philosophical argy-bargy without any concrete, well-grounded argumentation. I'm just baffled for why none of you guys crying wolf even tried to ask me reasonably productive questions of what do I actually do in my setup.

- My LLM use is mainly not about code generation. Especially it is not about autonomous code generation and execution.

- Why nobody's asking about scope of the LLM file access, audit logs, tool use confirmation, allowlists/denylists, rate limiting/circuit breakers - pre-tool hooks, scoped tool sets per context, etc.?

Whatever. If you think it's unsafe - just don't do what I'm doing. Just please spare me from security-as-ritual, I don't believe in prayers, I preach security-as-engineering. None of you proposed a threat model. None of you started with: "here is the specific attack, here is the attack vector, here is the probability, here is the blast radius", it's all just: "imagine what a baddie could do" followed by an escalation chain that terminates in total system compromise. By that reasoning you should not run any software.

[h3lp]

In the interconnected, online world, you can do more damage without root access

     "they can read my email, take my money, and impersonate me to my friends, but at least they can't install drivers without my permission"

   https://xkcd.com/1200/

[iLemming]

So? My terminal has the same full system access. If I didn't use Emacs, I'd be using Claude code in it. It's contained locally on my computer, I don't see any problem here. I use Emacs like my OS-layer. Why would I complain that my OS has access to something? It would be weird and annoying if it's the opposite.

[habinero]

Yeah, that's incredibly unsafe. You made a footgun machine and you're firing it with no shoes on. Don't run that on any machine with credentials you care about.

At the very least, run it in Docker. It's not a security tool, but it's at least some kind of guardrail against data loss and exfiltration.

[iLemming]

> Yeah, that's incredibly unsafe.

Having a browser on your machines is unsafe. The browser is a massively more dangerous attack surface than an Emacs-based LLM tool. What I have is a curated set of Lisp functions exposed to an LLM through a protocol I control, running in a single-user process, on my machine, behind my firewall. The attack surface is comically small by comparison.

[i_think_so]

<insert: Friendly reminder to replace Docker with Podman>

> It's not a security tool,

Amen to that, brother.

I'm sure somebody can google up a better example page than this. https://web.archive.org/web/20260322141827/https://www.simpl...

[Blackthorn]

You have to give Claude Code access to every shell command individually unless you run in yolo mode.

[forty]

I don't think it's very reasonable to use claude code on a computer that have credentials without some kind of sandboxing or validing every command it does, at which point I'd rather do things manually

[iLemming]

Ah come on, guys, let's talk pragmatically. "Malleable editor as an OS layer" has benefits beyond subjective reasoning. Emacs has had M-x shell-command and arbitrary elisp eval forever. A metacircular MCP isn't some new capability class. Even if I didn't use Emacs - my shell, my editor, my browser extensions, my npm install, my VSCode plugins, my curl | bash from yesterday - they all have the same access. Singling out the LLM in this context is like selection bias.

Of course, reasonable mitigations are a must - just like for any other tool. Narrowing MCP scope - tool routing rules, read-only git defaults, etc. "Docker or nothing" is a lazy answer - Docker-for-everything has real costs: friction, broken integrations, worse ergonomics.

Practical security is all about staying in the goldilocks zone. You shouldn't get relaxed about the basics - sandboxing, 2FA, password managers - they are worth doing, and you can get so paranoid about so many things, and yet against a targeted, well-resourced attacker, your sandboxing posture is mostly irrelevant. The interesting attacks bypass the threat model entirely. Read about Ben Nassi's team research¹ - pretty cool example. There are multitudes of other ways and your Docker container won't stop them. Defend against the boring 99%, and accept that the 1% is someone else's problem (or a much bigger problem than your dev environment)

—

¹ https://www.nassiben.com/video-based-crypta

TLDR LLM Summary: Researchers showed that a device's power LED subtly flickers in brightness and color while the CPU performs cryptographic work, and these flickers leak information about the secret key. By pointing an ordinary video camera (an iPhone or an internet-connected security camera) at the LED and exploiting the camera's rolling shutter, they boosted the effective sampling rate from 60 to 60,000 measurements per second, enough to do cryptanalysis. Using only this video footage, they recovered full ECDSA and SIKE keys from a smartcard reader and a Samsung Galaxy S8, with no malware on the target devices.

[habinero]

It's your computer and you can do whatever yolo nonsense you want, my dude, but put those goalposts back where they were.

"Don't run that shit on a credentialed box with data you care about" is addressing real threats, not some goofy nation state thing or abstract security research.

If you let the footgun machine constantly generate new code and run it on your computer, you're just asking for data loss and bad shit to happen.

Docker isn't a great solution but it at least doesn't let yolo code delete files or access env vars or read the contents of .ssh/

> my browser extensions, my npm install, my VSCode plugins, my curl | bash

Yeah, and you shouldn't yolo those, either lol. If they didn't come from a trusted source, you need to read through them. If you don't want to, don't use them. That's not paranoia, that's, like, normal.

[noctuid]

There are many better sandboxing options than docker (in terms of security and/or ease of use), and it sounded like you weren't doing sandboxing.