2 seconds. All right. I think we are live.
Yes. So, hi again, everyone.
I have the pleasure to welcome John Wiegley
in person to this EmacsConf.
Hi, John. Hello there.
How are you doing, Leo?
I am doing fantastic, and even more now that
I am in a room with you because we've been,
we were reminiscing with Sacha.
So you had been there in person in 2013 And
since we started doing those online,
Juan, since 2019, I think you've always been
online, right? Usually it's a pre-recorded
video. I think this will be the first 1 I do
live in a long time. You're right.
I'm saying we are online right now,
but I just meant pre-recorded video.
So it's good to have you almost in person or
at least live and we are excited to hear
about some of the Emacs news.
So the floor is yours.
All right, well welcome everybody.
This is the yearly state of the Emacs union,
I guess, about how Emacs development is
going. Just to note, I am not currently a
maintainer of Emacs. So what I do to get
these notes is I call up my friend,
Eli Zaretsky, 1 of the current Emacs
maintainers, and he and I sit down for an
hour, and he just gives me his dump of what's
been going on. So I'm sort of just the
messenger here. But thanks to Eli for these
notes and all of the efforts that he
contributes. So what he's been telling me is
that this Emacs 29 release that we had
recently looks to have been very,
very successful, which is some good news,
because there were a lot of new features,
and some of those features were actually
quite radical. So far,
it's been quite a success,
no serious problems with it,
and we have Emacs 29.2
will be released very soon.
They are thinking now about starting the
Emacs 30 release cycle soon after 29.2
is released, where the release branch,
which is called Emacs-30 usually,
will be cut and then development will become
frozen with only bug fixes going into that
branch. That may take quite some time until
it actually comes to fruition as a release,
but at least it means that the release is
going to start taking shape in that branch
soon. So, for now, Emacs 30 looks like maybe
it's going to be a little less interesting
than Emacs 29 was, meaning not a huge number
of changing features. But there are still
some new things going in.
So 1 of them is that Emacs 30 is going to
have Android support. So you will be able to
run Emacs 30 on your Android devices.
So if you've ever wanted to have native Emacs
on a tablet, which I know I've always wanted,
that will become possible with Emacs 30.
There's also going to be much better support
for touchscreen devices,
coincidentally, both laptops and tablets.
So that'll enhance that Android support.
There will be some recently gained support
for LLDB in GUD.dl. So if you're on a Mac OS
machine or a machine that uses just LLVM as
part of the compilation process,
then you probably are familiar with LLDB as
the command line debugger.
And that support for using LLDB through a GUD
will become possible in Emacs 30.
I'm looking forward to this actually quite a
bit as well. C Perl mode is being deprecated,
and all future work now is only being put
towards C Perl mode. Another 1 is that there
are going to be some new major modes based on
TreeSitter. They will be for the languages
Lua, Elixir, and HTML.
And if you're not familiar,
I think TreeSitter was introduced in Emacs
29. It's a library that allows you to specify
the grammar of a programming language as a
BNF file, and I think using JavaScript,
and then with that file as input to Emacs,
it is then able to do syntax highlighting,
syntax discovery, all of those things within
Emacs without having to use elisp and regexps
to discover the structure of the language.
It defers the structure gathering to
TreeSitter and then uses that information to
navigate the language.
So, As time goes on, you'll see more and more
languages taking on TreeSetter support.
So the next 3 coming up,
Lua, Elixir, and HTML.
And then the last feature for Emacs 30 is
that the byte compiler will now detect and
warn about many more questionable constructs.
Things like empty macro bodies,
missing lexical constructs,
or say, condition case without any handlers.
Just silly stuff that might litter the code,
but now you'll get a warning about it from
the byte compiler to help you clean up the
code and get rid of those potential sites of
error. So this is the main thing that will be
worked on for Emacs 30 and what's looked like
shaping up for the release.
And also, he wanted me to announce that
Stefan Kongas is now a new co-maintainer.
And Stefan is, I believe,
here with us in the conference and he'll be
able, I hope, to help me answer any questions
about future Emacs development because I'm
not in the heat of it and don't have all
those answers at the moment.
So That is all there is as far as a
development update for now.
And I am available to take any questions.
All right. Thank you so much,
Sean, for being the messenger of all this
good news. I mean, you did start by saying
this would not be as exciting,
perhaps, as prior releases of Emacs,
but you then proceeded to say a lot of stuff
that it felt very exciting to me.
So good, good. Glad to hear that.
Right. So we do have questions coming in
already and again people the link is on IRC
and also on the talks page if you want to
start asking questions.
So John what I'm going to do I'm going to
read you the questions and then you can
answer them. Is that okay with you?
Absolutely. So starting with the first
question which changes in recent Emacs
releases are you enjoying using?
I have really liked the visual line mode.
I'm not sure how recent that is.
Some of these features I only discovered
quite late, the new display line number
functionality, where it's much,
much, much faster, and of course,
native compilation. Native compilation has
been quite brilliant for some of the larger
packages that I use. I do a lot of stuff in
Emacs. I use GNU's, I use E-Shell,
I use Org Mode quite a lot.
So native compilation has brought the user
experience much closer to a modern app than
some of the lagging and slowness that I might
have experienced in the past.
Definitely. Moving on to the next question.
What do you think the future in the area of
artificial intelligence from the developer
point of view? Could you say that 1 more
time? Your voice broke up a little bit.
Oh, sorry. What do you think the future in
the area of artificial intelligence from the
developer point of view?
Could you say that 1 more time?
Your voice broke up a little bit.
Oh, sorry. What do you think the future in
the area of artificial intelligence from the
developer point of view?
It's also a shaky question,
I think, but you get the point.
I do use chat-gpt-shell inside of Emacs quite
a bit, actually, when doing development in
other languages. Just the other day,
I was working on my Ledger accounting
program, and I haven't done a lot of C++ in
recent years. So I had forgotten how to
exactly compare 2 strings only up to the
length of the shortest string.
I know I could have cranked that out just
writing it C style, but I didn't remember
what the current state of the art is for C++
and the STL. So I just asked chatGPT.
I asked the exact question that I just said
to you and sure enough it popped out the
one-liner that was exactly what I needed.
So I think in terms of developer assistance,
not having to keep all of standard libraries
or common idioms in memory.
I don't know if other people are familiar
with Rosetta Stone projects.
They're projects where you have say a hundred
different languages and there's a particular
question, say, how do I read a file and copy
it to another location?
And then it has an instance of doing that
activity for every 1 of those languages.
That's a great database,
and I've used them quite a bit in the past
for remembering how to do certain things,
say, converting a string to UTF-8.
I think that AI does a great job of
completely replacing the need for databases
like that because you can just ask how do I
copy a convert a string to UTF-8.
Yeah exactly and you know especially with
languages which are tried well tried you know
it's very easy to get an answer that is
correct. But sometimes what I find bothersome
with this type of coding,
I think it's AI-aided coding,
but it's still coding,
is that, especially with C languages,
sometimes you're going to end up with
undefined behaviors and stuff like this just
because other people have been doing it,
not because the algorithm or the model was
trained with data that dates back to 10 years
ago. At the time, C++ was a little different.
Anyway, I'm not here to talk,
you are here to talk. Moving on to the next
question. People already get to hear my voice
plenty, whereas yours are much sparser.
All right. So, what is the future of Emacs on
macOS? I understand that there are too few
developers for the platform.
Is that still true? That's a good question.
I don't know what the current statistics are.
I've been a user of Emacs on Mac OS for
decades now. It feels like the,
There's also that Mac port version of Emacs,
which builds Emacs more directly using the
GUI libraries on the platform.
That continues to be updated with every
single new release that comes out.
So I'd say that the support may not be as
great as it is on Linux and other platforms,
but to this day I haven't suffered from being
a Mac user. Great. The only thing I remember
about Emacs on macOS was that emojis made it
inside the GUI first before they did it
anywhere else. That's the 1 anecdote that I
have on MacOS. Right. And historically that
feature was removed in order to prevent Mac
from having features that Linux did not.
I didn't want to go into that point.
I just wanted to mention the beginning of the
anecdote and people can find it out.
But yes, that's also what it led to.
Moving on to the next question.
Why aren't you contributing to Emacs anymore?
Lack of time, I guess?
Lack of time, primarily.
Work has been very consuming.
There are a lot of other projects and things
that I like doing. I still find Emacs Lisp
very, very fun to write.
Just the other day, I was hacking up some
extension macros for myself for org mode.
But to have the time needed to sit down and
design a whole new mode and work on it.
I've been spending a lot of my time now in
functional languages, especially theorem
provers. I just find that so intellectually
satisfying and interesting.
Plus it pays a lot better.
Never had a paying job as an Emacs list
developer. So when it comes to now just being
a fun language or a hobby language,
it is relegated to the time that I have free
when it's available. Right.
Well, the good thing is that it's kind of
like riding a bicycle,
you know, writing a major mode,
it comes back relatively quickly and still
enjoyable. You know, the other day,
actually, I took notes on a mode that I
wanted to write. There's an app I use on the
Mac called drafts, and I really love it.
I use it all the time.
I wanted to mimic the interface of this app
in Emacs. So I could use Emacs as my drafts
application rather than this separate 1.
So I noted down all the different user
parameters and how it should function and
everything to describe the app to myself as
sort of notes to get me started on that work
when I did have free time to work on it.
Somebody out there on the internet just saw
these notes, because I keep a lot of my stuff
on GitHub. They fed it to chat GPT,
going back to your AI question.
And they actually sent back to me a mode that
implemented everything that I had said,
which was effectively,
chat GPT, seeing that what I had described
was clear enough for it to derive most of the
code that I would have wanted to write.
So maybe, maybe another thing that AI can do
is it can increase the value,
the efficiency of my free time.
Exactly. I think that's a wonderful point.
And phrasing it as efficiency of free time is
great because you still have the expertise,
obviously, that you're mobilizing into the
design that you're formulating to charge DPT,
but then this expertise is turned into
something that actually works.
Perhaps we're all going to become software
architects at some point,
and then the busy work of actually coding the
library and the software will be relegated to
AI. That's an interesting future where we
still, however, need to acquire the skills to
know what is code, I suppose.
But that's an interesting future to think of.
A fairly long question.
So 1 of the tricky things about running Emacs
on Android is do you use anything that
requires extra packages?
Example like PDF tools with new PDF or going
with a database, playing music or video with
MPD or MPV on Bonga, LFeed.
Do you run Emacs Termex,
Emacs APK, Emacs in virtual machine?
This is also the case on Emacs for Windows to
a lesser degree. So summarizing,
how do you make Emacs work on Android if you
do not have the synergy of stuff that you
usually find on Linux systems like MPV and
all the fancy applications like this?
It's a good question. Since I'm not an
Android user and I've never tried running
Emacs on Android platforms,
I'm not sure what's available out there to
plug Emacs into. I mean,
effectively, that question comes down to
external dependencies and system support.
That would be a great question for Stefan or
somebody who has tried using Emacs,
the development version of Emacs on Android.
Great. We'll put a pin in this for Stéphane
afterwards. Great, so moving on to the next
question. Will Org Tech someday become the
default tech mode in Emacs?
And if so, when? Will Org what become?
Org Tech, you know, the LaTeX mode.
I do not know. It's been a while since I've
done LaTeX. It must have been like 4 years,
but it was a pretty, the major mode for
editing documents, like the state of the art
for editing latex documents in Emacs.
And apparently it's not default.
I assume there's latex mode or something that
is doing it. So were you saying octech,
like A-U-C tech? Oh, did I not pronounce the
C? Octech, yes. I thought you said org tech.
I wasn't familiar with that.
Octech is the only 1 I've ever used.
I know there is a built-in LaTeX mode,
but I've never used it.
I always just download whatever the latest
version of Org Tech is and use that.
I don't know why it's not a standard package.
Becoming a standard package has its own costs
for the development cycle because it slows
down release cycle quite a bit.
It's now you have to create PRs that are
reviewed by the Emacs Devel mailing list.
It is a little more inertia.
Of course, it gets you more distribution
because it's a default package now,
and everybody can be using that.
But it's not something every developer
decides to do. It took a few years,
in fact, to get usePackage into Emacs core.
And that only happened after it was so stable
that it really wasn't receiving many changes
anymore. Yeah, yeah it's it's the thing when
you move into core you lose a lot of your
agility in terms of how you're writing the
code or how you expand code.
That's why you have this vibrant community on
Melpa compared to core but you know it
doesn't necessarily ought to be this way it
could be a little different you know And it
feels like there's this repetition between
repartition, sorry, between people developing
for the core of Emacs and people developing
on Melpa, but at the end of the day those 2
groups are constantly talking to 1 another
and taking cues from 1 another as well.
So that's great. And there's of course...
May I jump in about this particular question
because I think I mean You know,
Org Mode doesn't really have any problems
with releases Correct.
Just because it's distributed with Emacs so
there is a difference between being in the
core proper and being distributed with Emacs.
And for something like use packages,
it's really necessary to be in the core.
But for something like major mode,
it's a bit easier. That's a very very good
point. Yeah, I'd forgotten about that
distinction. Org mode does advance pretty
rapidly and then it makes releases into the
core distribution. Gianni,
I believe you also wanted to say something
before someone started jumped in with a
question do you happen to remember okay
that's fine I lost her to lost to their time
I'll be moving on to the next question then
and by the way feel free to interrupt us you
know The whole point of this discussion is
for you to ask questions to John Wheatley.
So whether it be via the other pad or via
BBB, choose your weapon.
All right, moving on to the next question in
the meantime. And we have about 7 minutes
left of Q&A and then we'll be moving on to
Stéphane. So, do you use other IDEs for
theorem proving work, notably VS Code for
Lean? Which languages and provers can or do
you use Emacs for? I've only used Emacs.
I've used Emacs for working with ACL 2,
Coq, Agda, and Lean, and I really love
Proof-General. Coq is my favorite language to
be working in. Agda has really great support
as well, has a very nice Emacs mode.
I'm only just now starting to get into Lean
4. So I have everything installed,
but I haven't really started coding in
earnest. I'm still reading a lot of the
tutorials and learning a bit about the
language. There was a while there where I
used a IDE for ACL 2 that was outside of
Emacs, only because it was the same IDE all
my co-workers were using and it was easier to
share tips and tricks with them.
But yeah, no, I found Emacs to be a great
home for doing theorem proving.
Right. Next question. Can we see that AI
generated draft? You know what you mentioned
before about the draft that you then fed into
ChargPT? Do you happen to have this draft
anywhere? Let me see if it's still on GitHub.
Just take me 1 second to take a look here.
Take your time. The problem is I don't quite
remember where I made the note.
But no, I don't see it on GitHub,
so I don't have it readily at hand.
Well, that's fine. We'll be able to...
Well, if you happen to find it,
we'll make sure to add it on the pad and then
on the talks page. And I think we would all
be interested to see what this design
document that actually made something work
afterwards in JudgeDPT with Elisp.
I'm very interested to see what it would do
because I tend to be very interested about
this type of stuff I had generated but I
never thought about doing it with Elisp
because somehow it feels like 2 different
worlds, like Elisp is kind of from the past,
don't going me wrong, I love it and I use it
every day But it's 2 different parts of my
brain that I didn't think about linking.
So I'd be very excited to see this as well.
Moving on to the next question.
Oh, go on, please. I did find it.
I'm gonna have to give it to you as a link
here. Sure, you can do it on the blue button
and I'll put it on the pad.
I put it into the public chat for Bibi.
Yes. So if anyone is interested,
I'm putting it right in the answer to the
question right here on my screen.
So feel free to click on it and explore it.
I'm kind of curious, so I'm gonna...
Can I click it on stream and can we look at
it a little bit together?
Sure, sure. I haven't tried running it,
I can't say for its fitness,
but it's definitely enough of the groundwork
done that it's absolutely an assistance.
Right. Okay, so it's loading up right now?
You can see my webcam,
right? I can see your browser attempting to
load. There we go. Okay,
cool. So I'm not sure what GitHub is doing.
Let me give it a little more room.
The reactive setup is not working too well.
Oh, I see. You're viewing the...
I see. Can I see the file then?
I should be able to see the file.
I think he just mentions the code in that
comment. So if there's a way to view only the
comment it would make it clear.
Right. Okay. I'm loading the file separately.
I'm checking the time.
We have about 3 minutes left and I think we
have a question. In the meantime,
whilst I show this, I'm gonna launch another
question, which was about Drafts.
You are carrying, you're talking about
Drafts, but does that mean you're not using
org anymore? Oh, no, I use org all the time.
In fact, the way that I've configured drafts
is that after I type the thing in the note
into drafts, I hit a key and it creates an
org mode capture item for it.
The reason why I use Drafts instead of Emacs
is because it's always available.
If Emacs is currently doing some job for me,
say I'm running some long-running subshell
and the UI is frozen up whatnot,
Drafts is always 100% of the time instantly
available. So that's why I tend to then lean
on it a bit, but all of the destination of
that data is still Org Mode and everything
that I do gets tracked through Org Mode.
That's also why I wanted to implement the UI
scheme of drafts in Emacs so that I could
drop the use of this external application.
And then, I mean, I would still have the
problem of sometimes Emacs being unavailable,
but I would pay that price in order to have
that good UI of drafts inside Emacs.
Great. I think we have,
we might be too tight on time.
We only have about 2 minutes and I need to
jump room to go into Stephane's room as well.
So John, where I get to thank you so much for
taking the time to answer our questions,
but also doing a little bit of reporting on
the state of Emacs. And now we'll get to
continue this with Stéphane.
So do you have any last words for everyone,
John? No, no. I look forward to hearing
Stéphane speak. Okay, great.
And we'll look forward,
potentially, to having you again next year,
potentially still doing news like this,
and, fingers crossed, maybe having you live
again. Maybe, maybe let's see what happens.
All right, John. Thank you so much.
Bye bye. Bye bye.