So let's, I'm just going to answer
the questions as I see them on the pad.
So yeah, this first question is really good.
And I think it's actually this great thing
that I did not mention is that like,
if you have unsaved buffers,
which is, you know, when you're actually doing editing,
most buffers are unsaved.
really you need something tightly integrated with Emacs
to deal with that.
So things like, you know,
I demonstrated Copilot,
I demonstrated Gptel,
things like those things, things like Ellama,
these things will all work with unsaved buffers
because they work via, you know, the input is the buffer.
as opposed to a file.
Things like Claude Code, Gemini Code, et cetera,
those are working with files.
They have no idea what is going on with your buffers.
And it could be that you can solve this problem
by using this thing called MCP,
which kind of gives the coding agent
a way to see anything in particular.
In this case, it would be Emacs
and the state of your buffers.
But I think that's not a particularly great solution
if that's how you want to work.
But I think that's kind of like
if you're in the Claude Code
that kind of world where you know things are happening,
basically through a terminal.
It's okay, like you typically
would not be doing a mix of things.
You would just be doing things either
in one place or the other place.
You know, it could be that you switch off
from one place to another,
but you wouldn't be doing both at the same time.
And it's kind of a, you tend to just fall into one,
you know,
editing outside the editor or editing inside the editor.
And I find myself switching between the two
when I use those kinds of tools.
So David, let me interrupt you for just one moment.
I want to just take care to read out
the question that we're answering.
The question was, my biggest question with AI code editors
trying to integrate with Emacs is,
are the AI code editors able to read unsaved buffers
and not just saved files?
Sorry. Yes. Yeah. Thank you for reminding me to.
I will read the questions from now on.
But yes, that's what I think about.
that interesting questions about unsaved buffers.
The next question is,
I don't agree with the comment you made
about VS Code usage dying out
because I see companies and products
pushing for tightly integrated agent
and products like Windsurf.
So thoughts on that?
Yeah, I mean, it's really hard
to be certain of anything,
like things are changing very fast
and it's very hard to predict the future.
But the trend I see is that um,
the sort of outside editing experience
where you just kind of instruct a model,
what to do is getting better.
And as long as that keeps getting better,
I think that's going to lessen the demand
for these tightly integrated editing experiences.
So it could be that, um, a lot of people,
especially in, you know, corporate environments
just start using,
they're going to use whatever is
going to make the most productive.
And I think right now, it's not clear that that will be,
you know, the very agent-based, you know,
command line-centric way of doing things.
But it certainly, the trend is, if that continues,
I think it probably will be like that.
So I think we'll have to see.
I don't think your opinion is unreasonable.
I guess I'm kind of cautiously saying
I think it's gonna be the opposite, but I guess we'll see.
Like, let's reconvene in a year and see what happens.
Uh, the 3rd question answer,
do you have any thoughts about the environmental costs
of using either the training
of the models are we can download or use locally
or the larger commercial models used from the cloud.
Um, I think. The, you know, I'm on social media,
probably a little bit more than I should be.
And I do see a lot of discussion there
and a lot of concern about the environmental costs of using LLMs.
I've looked into this as I'm also concerned
about keeping my environmental footprint personally down.
And I do this in many ways,
but I certainly don't want to kind of like blow that all the water
because I'm using LLMs so much.
I think that the concerns are mostly overblown.
There's a concern that, well, it uses a lot of energy.
In aggregate, the total amount of energy
used by the data centers in the US is a few percent.
And this is a fraction. I think this is like LM's account
for something like 20% now
of all data center usage, which is a lot.
But Those data centers are doing lots of things.
They all need to be water cooled.
Um, if you like per LLM prompt,
the costs are relatively small
and by relatively small, I mean,
you know, people have said online,
well, it's like a few bottles of water per prompt.
That, that is not true. It is much, much less than that.
It's a fraction of that.
So, uh, I don't think the answer is nothing,
but I would say it's, I would say you probably,
if you want the most bang for your environmental buck,
probably the best thing for you to do
is take less flights and things like that.
Like, yes, you can cut down on this,
but I think it's pretty marginal at the moment.
We do probably need to think about the total costs
like of humanity using all of this.
Like a lot of stuff you'll see
corporations are using a lot of these things.
And so like, just like if you look
at water usage or energy uses in total,
it's like really corporations that are using this.
So there might, there's a lot of leverage there
to make things more efficient as opposed to personal use.
So I think it's wise to be cautious,
but I think it's okay, I think, at least for personal use.
The next question is another,
yeah, this is also disagreeing with me about VS Code,
but it says, I must say I liked your conclusion,
but I differ insofar as you said that VS Code differs from Emacs
because the former is not as easy to adapt as the latter.
But why should Microsoft not adapt VS Code
as we adapt Emacs for the new era of coding?
And why would VS Code be harder hit?
Could you please elaborate on this point? Yeah, thanks.
This is a good question.
I think maybe I wasn't as sharp on my point as I could be.
Because I think the core
of what I'm saying is like, there is a going to be a trend.
I believe there will be a trend away from editing.
And if we are going to be editing less,
I think VS Code, like people will be in editors less.
And that means people will be in VS Code less,
people will probably be in Emacs less.
And yes, I think you can, VS Code
is to some degree extensible.
but I think there's less of a community, or that is,
I think the people using Emacs
have used Emacs for a long time.
They're going to continue to use Emacs.
I speak for myself, but I know
a lot of people here are kind of like this,
and they're going to just, like,
we have a lot of momentum to keep doing things in Emacs,
and especially because we have a lot of things
that we already do in Emacs.
We do to-do lists and, you know, with org mode
and some people read email
and some people are using
shells in Emacs and all these things,
I think will make Emacs
kind of a better environment
if you want to do various editing like things in Emacs.
In, you know, in an editing environment,
because I think just emails can edit
more types of things I think will naturally
be a bit more useful than VS code,
which people are really just using to edit code
and if people find it less useful to edit code.
I think it's VS Code will be harder hit than emails
because that's its whole, like, that's in the name,
like the whole reason for it
to be doing things as to edit code.
So I think that it's it's vulnerable
in a way that Emacs isn't
just because Emacs is so very...
you know, it's, it could do so many things
and and people use it for so many different kinds of things
that it's I think it's going to be
a little bit more resilient.
But as I said with the present.
For those of us that are using Emacs,
it's everywhere for us.
Not necessarily everyone is an I live in Emacs person,
but whatever you're using Emacs for,
it is the thing you reach for to do that thing.
Is that touching on the point?
Yeah, that's a great way to say it.
Thank you. Thank you, Corwin. Yeah.
Thank you. Thank you for that question.
Do you think we're falling behind in productivity as Emacs users
compared to all these VS code forks
that have a thousand button and text boxes everywhere,
which are basically much richer UIs,
which are basically web pages?
I do think Emacs is falling behind in some ways.
I mean, it's definitely showing its age a little bit,
especially you mentioned richer UIs
that are basically web pages.
I mean, this I think is one of the big problems Emacs has
is that it uses a very, you know, a much more ancient way
of kind of doing UIs that is not particularly flexible
and not particularly comfortable for any modern UI coder.
And I think if you look at the Emacs stuff out there,
like, yes, you can do a few things with UIs.
You can have some amount of UI richness,
but it's pretty limited.
And I kind of, if there's one thing
I could wish for in Emacs,
it's sort of like, I kind of wish Emacs could be on a,
could be built on top of basically like Atom or something like that,
where it's like a web framework
that allows us to write actual rich pages,
rich UIs in a modern style using things like CSS
instead of the kinds of things Emacs lets you do.
But that said, that is an advantage
of VS Code and other editors like that.
I think that Emacs does a good job
of eventually catching up
to all sorts of things people are doing in other editors.
It's often that other editors get there first,
but there's a lot of momentum
to kind of keep Emacs fresh, keep it modern.
And it's pretty easy to- I love that.
I forgot about the lag. We do have a little bit of lag,
but I just, I find that very captivating.
We have with technologies
like Apache Cassandra in the database world,
we have this idea of eventual concurrency.
And you make me think with Emacs,
we have this idea of eventual feature parity, right?
If a feature stays desirable long enough,
Emacs will eventually grow it.
I think that's a very contagious idea. Yeah, yeah, thanks.
I hope that idea makes sense. And I hope it's correct,
because I think that I do want Emacs to continue to succeed.
And I personally, using Emacs,
do not feel myself falling behind in productivity.
That said, there's a lot of ways that Emacs can improve
and should improve on this front.
And a lot of these ways are pretty fundamental.
So I kind of hope people pay a lot of attention
to some of these more fundamental lower-level Emacs things
that really allows the packages
to do more richer and better things.
Sorry, you have a ton of questions.
I shouldn't be doing so much active listening.
No, no, I appreciate your input.
OK, next is I've been using Claude Code extensively.
I recently switched to Agent Shell with Claude Code.
Have you tried it? And what are your thoughts?
I actually have tried Agent Shell.
And currently, I recorded this video like three months ago.
So Agent Shell did not exist then.
If Agent Shell did exist,
I probably would have demoed it as well.
Agent shell is great in the sense of it's...
It does use comint, which is the way that I think all Emacs users
would prefer to interact with something like Claude Code,
or any of those types of tools, which is like, I don't.
Um, the other,
but it's a trade-off it uses like on the back
and it's, it has a common buffer.
And then on the back end, it's using a protocol
to talk to agent, uh, to Claude Code and other things.
The problem is this has a lot of problems.
For example, like you don't have
completion of slash commands.
You don't have, um, if you ask to see the, in Claude Code,
you can get a visual representation of. the context window.
But you can't do this. I mean, last time I tried,
I couldn't do this in agent shell.
It's progressing rapidly.
But it's not as rich in functionality
as using Claude Code directly.
On the other hand, because it's letting Emacs be Emacs
and using comint, it's a much better experience
to actually give instructions.
I think the maximum power, though, is, to me,
the best way is still like, you know,
do your editing in org mode,
and then just tell, you could have,
you know, the richer experience of using
of using Claude Code in, in it's more like shell like form
where everything is, it's much, you know,
designed to be used in the terminal,
but you don't have to type in that much
because you're really doing your typing
in order to me, I think there's
kind of the sweet spot that I like.
Um, but agent-shell is a great step forward
and I think it's, uh, it's quite good to use.
And I, I personally use it a lot.
Um, OK, so in terms of, next question,
in terms of agent selection,
what has been your experience with different agents?
And have you had any success with hosting your own models
and using open weights?
I think there's, you know, many people
have many different opinions on this.
I think Claude Code is, most people I know
would say Claude Code is probably,
sorry, Claude is probably the best for coding right now.
Gemini can be very hit and miss even with 3.0,
but Claude is quite good.
4.5 Opus is actually relatively cheap
compared to the previous version of 4.1 Opus.
There's other models out there,
but I think most people just stick with Claude
because it's very reliable, it's very good,
and nothing is obviously better than that.
And as far as DeepSeek is pretty good as well,
and then much cheaper.
I've had some good luck using that locally,
but actually the problem is for my day-to-day machine,
like my personal machine,
it's not powerful enough to run anything locally.
And my work machine, it is powerful enough,
but I can spend my company's money at will
on more powerful models.
So there's really not a lot of incentive
for me to run locally.
I think, as far as I know, I haven't heard
of local models being incredible,
but I think you can get reasonable quality with them.
That is, especially if you're doing
relatively simple things,
I think it's pretty reasonable to be using those.
Also, they tend to be slower
than the models that are elsewhere
just because they just have more horsepower,
they can churn through those tokens a little quicker.
[Corwin]: So, I'll just break in here to say,
we've got about 7 minutes left
before we're cutting over this great discussion so far.
I'm very happy to keep going.
There's no time limit, but at a certain point,
I may have to leave
to jump in and prep with the next speaker,
but you'll be able to keep going
as long as you have the steam for it.
[Andrew]: Yeah, I think we have 3 questions. Yeah, thanks.
I think we have 3 questions.
Let's see if we can get through them
all in that time period.
OK, this one is interesting talk.
I'll start by asking it for everything, but is it editing?
I think there's more of a comment than a question.
So yes, let us all ask, but is it editing?
All right. I can move on to the comment area.
I'm reading angst in your thinking about AI editing.
I think that's true.
It says, and the question continues with,
what are you excited about?
Wow, that's an interesting question.
I mean, I think there are possibilities.
Like, yes, people are going in sort of a relatively obvious direction
with LLMs right now.
And I think there's lots of opportunities,
clever opportunities to do things
we couldn't have thought of... Things that are useful,
but in ways that are not super obvious to us,
and I think I'm still excited
about the possibilities of using them in ways that are super helpful
and different than normal. I'll give you an example.
This is something that I intend to, I think,
post on Reddit in a few days,
but I have a extension to eshell
where you can prefix a command with at,
and then just tell it what you want to do,
and it will substitute the command
that you are thinking of. Because often, I do not remember.
I never remember, like, how do you find a file in a directory tree,
you know, recursing? Who can remember how to do that?
It's like a find, and there's like a dash print there somewhere.
Yes. There are some smart people who remember this
but I am not one of them.
And so I think, like, something like this is like, you just type out,
find me this file, and it will substitute
the correct command.
I think this is, there's a lot of little,
little tweaks you could do like, you know, if you want the AI,
it could be there for you, and it will help you.
And if you don't want it,
it's not going to get in your way.
And I think this is where Emacs can really shine.
It can really take advantage of LLMs,
but still remain true to its kind of editing experience,
because it's not forcing you to use LLMs all the time.
So thank you for that great question.
And then the final question. Yep.
This final question is, why does it matter to have a richer UI?
All this left is basically running and getting the results.
I think maybe this is a response to me complaining
about Emacs not having a richer UI before,
but I think it does matter a lot for all sorts of things.
It's hard to kind of explain succinctly,
because I'm talking about UI
and I'd have to show you things.
But it should be just something like, oh I have an error,
and I'm using flymake and I'm,
I'm using the... I have options
where it'll show me the error in line
by underlining things and having a little message,
but like, you know what, that message
doesn't appear quite right a lot of the times.
Or here's another one like. I program in Python a lot.
And Python, it's super hard to program in
unless you have these little vertical lines
that shows you what the indents are. At least I find it.
There are two packages that do that.
None of them do it particularly well,
just because Emacs at its base
does not allow you to do this.
And so you kind of have to hack it in.
And there's lots of ways to mess it up.
And when editing, you'll find yourself
messing this thing up regularly.
So it doesn't look quite clean.
And like, there's little artifacts,
or, you know, there's little ways that it,
it kind of gets things wrong,
or you can get things wrong with it.
So I think that, like,
there's a lot of issues with that sort of thing.
And also, like, you know,
what if you want to do something like play a video inline,
like, I don't know, you might should be able to do that,
you might should be able to do anything.
But right now, it just can't. I think
a lot of the reason as well...
you know, we wanted to be compatible
with TRS 80 machines or something like that.
This is important, this really is important,
but I hope there's some way
that we can kind of eventually figure out
how to get the best of both compatibility and
more modern UIs. So, you know, we can have more modern UIs
for people that have modern machines and other people
either do without that functionality
or sort of fall back to some reasonable default.
So we have about 30 seconds or a minute.
I know there's one more question.
I'd love for you to get to it.
I just want to make sure that
while we're still live on stream,
you get a chance to share
any closing remarks you might have.
Thank you for that. Um, yes.
So first of all, I want to thank everyone involved for listening.
And I want to thank the core when I think thanks for moderating this.
And Sacha, thank you for putting that together.
And I know there's more people
that are working behind the scenes.
So thank you all for putting this together.
I'm so happy that we all are here. We care about Emacs.
We're pushing Emacs forward.
We are I think Emacs remains
this really remarkable achievement.
Like it's amazing that it exists. It continues to exist.
It hasn't got... It's hard.
It's like, really, there's a lot of work to go into it.
So I think let's all just appreciate everyone
who contributes and makes all of this possible.
Cause it's, if you ever read
the emacs-devel mailing list,
it's a lot of work, a lot of deep thinking,
a lot of careful thinking.
And I think this is really important.
So thank you, especially to the maintainers of Emacs
and everyone who's contributing to the core experience,
all the libraries, all the LLM stuff we mentioned before.
You're all doing such a fantastic job.
It's exciting to be here.
[Corwin]: Thank you for your talk, Andrew.
It's been just fascinating.
If you don't mind, I'd love to jump
right over to the last question. OK, let's do that.
It says, I have 45 plus years editing programming.
I'm not sure I can think about things
without thinking of buffers, editors, et cetera.
Is this the handicap?
Should we have people with no experience
with code learning to prompt?
[Andrew]: Well, this is something I do have a strong opinion about.
I feel like I do not want to see people that have no experience
with code learning to prompt. I think it's very limited
what you could do right now with that.
Like you could do, if you could sort of one-shot it,
that is like, I have something that's relatively easy,
And it could do it, and I'm going to tell it to do it,
and then I'm going to give feedback.
OK, as long as this is for relatively short-lived things,
I think that works well. But for people who really care
about the longevity of their code,
really care about software engineering,
which is software engineering is very different than just writing code.
Software engineering is about maintainability.
Software engineering is making sure everything is scalable
and all sorts of things that it's unlikely,
I think, that an LLM is going to get right.
And I've seen a lot of bad cases
where people who don't understand code
are doing things and it's not working well,
because they don't understand
some of the complexities
or some of the concerns that that you might have
in maintaining a piece of code.
So I think those people who have lots of experience
are the best people to use this.
And I think that's what we're seeing
in the industry as well,
where more senior people are doing quite well
because they're able to use LLMs
more effectively than junior people.
That may all even out because LLMs get even better,
but for now hasn't happened.
So I think, you know, I also have a ton of experience,
not 45 years, but a lot. And, and I think that it's those,
those years of experience will only help you.
And I think it's great to dip your toes in the water
and see what you can do.