Hi, I'm Andrew Hyatt.
I'm going to talk to you today about Emacs and AI,
and where things are right now
in the world of Emacs and AI,
via large language models,
and where things might be going,
and what it means for the future of Emacs.
I think what we're seeing with Emacs is interesting.
We've seen a lot of different things
come around in the past year,
in the past several years.
There's lots of different solutions.
But in the past year, things have been very interesting.
I think there's new and interesting questions
about what does it mean to use Emacs?
What does it mean to use any editor?
I'm going to be talking about Emacs,
and I'm going to show you various Emacs packages
as demonstrations of these ideas.
But there's the general question of
what does it mean to use any editor, not just Emacs?
What does it mean to do work?
And I think the industry in general is facing these challenges
of we don't really know where things are going to end up,
but we do know the direction they're going.
Emacs is a reflection of that.
I think the answer for Emacs might be
a little bit different than everything else,
but I do want to show you what's out there
so we can explore what are the possibilities
of Emacs, AI, and generally how we get things done.
Thanks. Let's dive right into it.
We're going to start by showing you
some things that are pretty well integrated,
that look a lot like what you see in Emacs
and fit in with the kinds of editing
that you normally do in Emacs.
So this is just kind of like, it's well integrated.
So we're going to talk about Copilot and Semext.
Copilot is by Microsoft via GitHub,
and Semext is just my personal demo,
but they're both showing you, you know,
this kind of thing. Let's start with Copilot.
Let's try out Copilot on just a standard bit of Elisp.
We're going to write a Fibonacci function.
Let's try out Emacs on a standard bit of Elisp.
We're going to write a Fibonacci function.
And you can see like as soon as we even start typing it,
we get everything as a completion.
So you can just press Tab here,
and you've just completed
a significant bunch of Emacs Lisp code.
It will do this no matter where you are.
So, pretty useful. It will just keep suggesting things.
Do you want to do this?
I'm not sure.
But it usually is offering pretty reasonable things.
So you could do this with code,
of course, any code.
You don't really even have to have a mode for it, right?
That's kind of the beauty of AI is that
you don't need any Emacs functionality for this,
except for Copilot.
It doesn't need to know the structure of your code.
It doesn't need anything except for the text itself
and whatever AI integration that this is.
We can look at, you can do the same thing with Org-mode.
So we could say create, no,
how about let's, let's do, you know, spring cleaning.
It's actually the fall, but still we'll say spring cleaning.
And it'll start suggesting things that, you know,
maybe at first, it doesn't really know what to do to
clean up all code.
It thinks I need to clean up code, but no,
this is going to be actual, you know,
clean hood over range. Clean out pantry.
These are all really reasonable suggestions.
You just keep going here.
I'm going to demonstrate Semext,
which is a package I have on GNU Elpa,
that is designed to integrate AI in a very Emacs-like way.
And so what you could do is you could do a
semext-search-forward.
The UI looks just like other Emacs commands,
but you can search for anything.
There's really no way to express what I'm about to,
what I'm trying to demonstrate
in Emacs's normal search commands.
You could really ask for anything.
And it takes a little while, which is not Emacs-like,
but everything else is sort of like
it's designed to be like Emacs,
except way more powerful.
You don't need any mode to be active for this.
You just need the library
and an AI provider of some sort, either locally
or, you know, your favorite cloud provider.
Now we're going to move on to a different way
of interacting with AI and Emacs.
This way is less like the normal editing experience.
So you lose some familiarity. However, in exchange,
it is a lot more powerful.
And there's a whole suite of these tools.
I'm going to demonstrate gptel,
which is the most popular one.
But there are many.
And I think different people have
their own preferences of what they like to use.
We're going to try now something
that is a step away from just editing.
And we're going to, I'm actually using gptel.
There are several packages that are going to be
doing the same sort of thing as I'm going to show you.
gptel has sort of become the most popular one.
So that's why I'm showing that to you.
But let's just highlight everything and say gptel rewrite.
And gptel basically just has a few things.
There's different ways of thinking about this.
With just a few very configurable menus,
you can do a large variety of things.
So let's give rewrite instructions.
"Turn this into an iterative program
instead of a recursive program."
In Elisp, you really should not be using recursion.
So we could say "return to be ready".
Do we accept it?
Yes, we accept it. Or we could iterate and say, no, no,
that's not what we meant. We meant something else.
Or you did something a little something wrong.
Please fix it.
So this is all very powerful.
Is this editing?
Well, it's in the editor.
You could do this while editing, while deleting,
you could be doing some sort of traditional editing.
And then this, which is editing
in the sense that it's in your editor,
you might have to highlight
some parts of the file and do things,
but generally you don't even need to,
or you go to a spot and you say, put code at this spot.
It's kind of like editing.
I would say it's not exactly editing,
but it's at least something that must happen in an editor
and it's well integrated into Emacs.
As you can tell, it used very sort of
modern standard Emacs UI paradigms
and it's all written in Elisp.
Everything is happening in Elisp here.
So this is just very much an Emacs experience.
It's just not exactly editing
because the thing doing the editing
is the AI and not you.
You're just kind of telling it what to do.
Now we're going to go and look at a way of interaction
that's even more powerful
and even more disconnected from the normal editing experience.
In fact, it's so disconnected
that most people are using this without an editor.
These are things like Claude Code
or the sort of open source equivalent, Aider.
There's a few other things that follow this pattern as well.
But it's very interesting in the sense
that while you can integrate these with the editors,
and I'm going to show you an Emacs integration,
you don't need to.
And that's not the way most people are using them.
And I find it very interesting that sort of
we're going back kind of full circle where, you know,
in the 1960s or 70s, we were using Ed from the terminal
to edit files, but then we created editors,
and that was a really good idea.
It is a lot easier to edit files
when you have an actual UI.
But now it's 2025, and we're back in the terminal,
and we're editing files through the terminal,
and you know what, it's great,
but I think it's even better with Emacs.
On the other hand, it comes with some trade-offs,
as you can see, as we will see.
Okay, we're going to look at
[audio glitch] Claude Code IDE, aidermacs, ECA.
Last time, I didn't show you all the variants.
I do want to show you eca, which points to,
it is a very similar tool in what it does,
but does have a different
and I think better type of Emacs integration.
All right, we're going to demonstrate Claude Code IDE,
which is one of three Claude Code packages.
It's a bit confusing.
One of them will be demoed by another presenter
at the Emacs conference, so stay tuned for that.
Here I'm just going to give you a little taste
of what these packages look like.
So if we say Claude Code IDE,
it presents us with basically
almost exactly what you would get
when you're running this in the terminal.
And essentially there's a terminal interface.
You can see that there's a vterm.
But here we're going to say, "In scratch.el"...
let's say what we want to happen.
[In scratch.el, there is a fibonacci function.
Can you add all normal elisp headers
and footers to this file?]
So, we just say what's going to happen,
and this is going to do things in the background.
It's not going to do things through Emacs.
That said, there is an integration with Emacs,
so that it can do things like show you these nice ediffs.
My screen is not really wide enough
to show you a really great ediff here,
but you can kind of see what it's doing,
and you can see, yeah, that looks good,
so you could say yes, yes, accept the changes,
and if we... Just need to revert the buffer.
We can quit the printout of this.
We see that it just did everything I asked it to.
Is everything exactly right?
Probably not. It's reasonable for a start though.
But you could ask it to do anything.
You could say, write unit tests for this, and it will.
You could say, write me a suite of functions
like Fibonacci, and it'll probably do something reasonable.
But you can see this is not editing.
There's nothing editing-like about this.
That said, there is something that is editing.
You need to give it instructions.
You need to tell it what to do.
And what you could do is... You could have a project.org,
and what you could do is you could have functions.
The way I've done things often is ....
You could say something like,
unit tests for Fibonacci. How do you spell Fibonacci?
I don't remember. But then you could say that this is,
you could clock it, basically. org-clock.
What I've done is...
You could add custom commands to Claude Code,
and you could just say, look, here's my Org file,
read it and do the thing that I'm clocked in as.
And then you can write a bunch of instructions here, like,
I like to use ert for tests. Tests should, like, whatever.
You should just say... everything
you need to kind of specify.
As you get to more complicated tasks,
it's harder and harder to give it all the context
it needs for a task,
and Org Mode is actually a pretty good way to do this.
I find that this works pretty well,
and you can even have it instruct Claude
to just mark things done in your Org file
when they're done.
And it knows how to do this, of course.
So, let's just clock out.
That's one way to do things.
So one other thing I'd like to show you is eca,
which, compared to Claude Code, ECA is open source.
It's very nice in that respect.
It doesn't have to use Anthropic's models.
You can use local models,
but it has the advantage of integrating very well with Emacs.
I'm not going to demonstrate it,
because it works essentially the same thing you could do
approximately the same kinds of things
you could do with Claude Code.
You just write what you want to happen
and it will make it happen.
It again does not do this through Emacs,
but what it does do is
it gives you a much better Emacs interface
that's not terminal-based,
because you're not using it through the terminal,
or not even through comint,
you are using it through a backend
that is exchanging structured information
with this process that is doing all the work.
But other than that,
it's the same model as Claude Code
and projects of that nature.
We've seen in the demos that I gave
that there are AI experiences
that are very natural in the world of editing.
because they, like Copilot, just offers completion,
it fits very well with what we all do in Emacs.
And it's truly, yes, it's kind of a cheat in a sense
for editing experiences,
because it can do so much, but it's just editing.
Whereas things like gptel and those kinds of tools,
they are clearly in an editor and using editor,
they're using Emacs, but they represent sort of like, well,
you can edit for a while, then you could use these tools
to do something that is not editing,
this AI just changing the buffer for you. And that's fine.
It's still... It may not be editing,
but it's still clearly something that
is useful to do in Emacs
and belongs in Emacs.
But the new tools like Claude Code and things like that
are kind of different.
Yes, they will get better integrated with Emacs,
but it's not clear that they really need to.
They can do a lot of things without editing.
In a sense, editing is obsolete in some sense.
For as many tasks, you don't need to edit anymore.
And that's a nice thing.
No one really knows when all this will end,
how far things will go. It could be that in a decade or so,
no one's really editing for work anymore.
Maybe you're just writing instructions.
You could do that with anything.
You don't need Emacs or any special editor.
We could all be using Notepad. That would be bad.
But... I think it could go that far,
but it could be that, well, for many specialized things,
people are still using editing for certain tasks,
but most tasks are getting fed to just...
AI is just doing those things.
In any case, I think it's clear that editing is diminishing,
the need for editing itself is diminishing.
And in such a world, It's interesting to think
where Emacs is headed, especially in relation to
all the other editors.
I think people will use Emacs less.
But I think other editors, like VS Code,
may simply disappear or be a relatively fringe tool.
And Emacs is going to follow its own path.
It's very extensible. It could do anything.
If there's one thing Emacs can do, it's adapt.
Emacs has been around for a long time.
It's pretty clear that Emacs will be around for a long time.
It might be that in the future,
editing is some sort of like an artisanal activity that we do.
It's kind of weird to think about it.
It's not like baking bread.
But it is the sense that AI might be
churning out code in the way, you know,
the factories are turning out bread,
but if you really want the good stuff,
you'll have to do it yourself.
I don't know if it'll be exactly like that,
but it could be that Emacs survives and thrives
in a very kind of specialized ecosystem of people
who contribute and use it in the way
it has survived and thrive right now.
And I think that's a really nice way for all this to end up.
There's the whole sense of how society will end up
if all this happens. I don't know,
but Emacs will be there for us when whatever happens.
So thank you, and let's help make Emacs the best it can be
to survive and thrive in the next decade.