All right. Hi again, everyone.
It's been a while. Well,
actually, it's been like 2 minutes tops.
We were just with John Wheatley,
and now we are with Stefan Krangas.
Hi. Hi. So as we said before,
Stefan is co-maintainer now of Is it the
entire Emacs project? How do you describe
this? Yeah, co-maintainer of GNU Emacs.
Right, perfect. So you know what?
Because I'm sure everyone is dying to hear
everything you've got to say in your
presentation I'm just going to shut up now
and leave the floor to you.
Do you need to share your screen or anything?
No. Okay great well I'll just cut my webcam
off I'll still be in the background so do not
hesitate if you've got any problem I'm still
around And I'll see you just beacon whenever
you're done. And I'll show up with the
questions. All right? Thank you,
Leo. And thank you, everyone,
for being here. I'm Stefan Kangas.
So as Leo explained, I am recently appointed
as a co-maintainer of GNU Emacs,
which a role that I'm fulfilling currently
with Eli Sretsky, who's been co-maintainer
for quite some time. So I got the question to
be a co-maintainer from Richard in August
this year. And of course,
when you get a question like that,
I couldn't not say yes.
So here we are. I can't tell you how excited
I am to have this opportunity to address the
community in this way.
I'm really humbled, of course,
to be part of it, and to be able to serve the
community in this capacity.
I've used Emacs, I think many of you might
also have used Emacs for quite some time,
but I'm going on 2 decades as an Emacs user.
My involvement in Emacs Lisp development is,
I mean, almost as long,
but my core development goes back only 4,
5 years. I have to also thank the EmacsConf
organizers who are doing,
I think, a tremendous job and have done a
tremendous job over the years in really
building and strengthening what I think is
this fantastic community of users and
developers and people interested in Emacs.
I actually had the chance to meet up with Eli
Sretzky, as well as another Emacs hacker,
Andrea Corallo, when I was at the GNU
project's 40 years celebration,
40 years since the GNU project was announced.
And it was very inspiring in general to meet
people. And I think EmacsConf should also,
I think, serve to inspire and sort of help
bring something to the type of work that many
of us are doing to improve Emacs,
whether it's in package development or in
core, to bring out the new and exciting ideas
and get people enthusiastic about Emacs,
about hacking on Emacs.
This is my little attempt to contribute with
let's say 2 things. I will first try to
present how we do Emacs core development and
why we've done some of the choices that we
have, because We have seen at times that
perhaps people aren't always clear on this or
that aspect. So maybe this will be
enlightening. I will also try to present some
kind of vision for what Emacs could be with
your help. Emacs is already very good,
as we all know, but we could be even better.
That's the reality of any type of software
development. So the overall idea of this talk
is to tell you, if you're an Emacs list
package developer today,
why you should become an Emacs core
developer, and the sort of steps that you
might want to take to do that,
or how you can help Emacs core development.
Even if you're just a user and you found a
bug, report it. Perhaps you have a feature
request that you'd like to discuss.
I think we need more interaction in general
between Emacs core developers,
typically on emacsdevil.gnu.org,
the mailing list that we use to coordinate
our development efforts,
between Emacs devil package developers and
users, Because there is so much great stuff
really going on in the community.
But I think sometimes the step to core
development seems big and perhaps even a
little bit scary. So I'm hoping to be able to
help bridge that gap, even if just a little
bit. We need more people contributing to
Emacs itself. And also a small disclaimer
here, in this talk I will only be able to
speak for myself, not for GNU or the Emacs
project, even if it's like a little bit more
official, but I will also try to give the
view of the project where it makes sense to
do so. Keep in mind, I'm only 1 of the
maintainers, the co-maintainer together with
Eli, and I can't just make decisions
arbitrarily. In a sense,
I'm as a co-maintainer and trusted as a
steward and trusted by,
of course, the GNU project,
but also by the community That we really
can't just take decisions,
I think, arbitrarily. Even if it sometimes
perhaps may seem so, or it may feel that way,
we really have to realize that we can't just
push too much of just a personal agenda to
the extent that it doesn't line up with what
is best for eMacs going forward,
and the more overall picture of that.
So there are limitations that come with the
job, if you like. So 1 question I often,
I actually got this week when I started a new
assignment at work, and I got the question
when I said I'm involved in Emacs
development. And then someone asked,
oh, is Emacs still developed?
Isn't it done almost? And I answered to that,
yes, we are still around.
We're going on 40 years now as a software
project. Not many projects actually can claim
that type of longevity.
But Emacs is among those few that can.
And of course, we have had some very exciting
developments in recent versions.
I think John just gave you an update on that.
But we had just some highlights out of many
highlights that you could give,
really, we got the TreeSetter support in
Emacs 29 that we now need to sort of extend
and develop. We have merged EGLOT,
so we have LSP support out of the box,
I think is a huge improvement.
Native compilation, of course,
a big feature. I mean,
that was Andrea's job,
really, for performance.
And it turns out that in many types of
workloads and the types of stuff that people
are doing, it often matters.
And we're hoping to make that the default,
perhaps already in Emacs 30.
So there are things that are happening that
fundamentally make Emacs better at a very
core level. So, of course,
why wouldn't you want to be involved in such
an exciting and, I think,
dynamic project? How is Emacs developed?
Well, this is, I think,
perhaps to some people,
a little bit more of a threshold,
if you like, because I think all of us know
really that there is exciting and cool stuff
that is going on in Emacs and has been going
on over the last couple of years and we'll
see even more of that,
I think, going forward.
1 thing is that communication still takes
place over a mailing list in 2023.
So we have emacsdevil at gnu.org,
and that's where we develop Emacs.
We use, we send patches back and forth,
we comment on patches.
And actually this workflow is very good,
if you're used to it. Because guess what?
As Emacs users, we like doing everything we
can in Emacs, especially the core tasks that
we're doing, such as developing Emacs itself.
Of course, you want to do that fully within
Emacs. So we hack Emacs Lisp in Emacs,
we hack C in Emacs, we respond to emails also
from Emacs, respond to bug reports,
manage bug reports. We do all that stuff
very, very smoothly. And it doesn't really
matter in a sense, what is the medium?
It happens to be email.
Technically it could be anything,
but email really has that type of staying
power where we've been able to use it for a
long time. And this is how,
and we're still able to use it.
And this is how free software was always
developed in the past.
Only in the last, let's say 10,
15 years, We've had more development taking
place perhaps on forges like GitHub,
GitLab, whatever. But we are 1 of the
holdouts. I mean, there are others,
of course, like the Linux kernel has mailing
lists. They're not trying to do that scale
development on GitHub.
And this is not just because we're Luddites
that refuse to change.
We just have to do it in the old way,
because it is the old way,
and that's the way it should be.
No, it's actually because we,
as core developers, the core development team
and the people already involved and doing
tremendous, I mean large amounts of work in
Emacs has very efficient workflows built up
based on this. So of course,
I mean moving to something else is something
that we might like to do,
but we're not yet clear on how to do it
exactly and what to move to.
So these are the types of discussions that
we're looking at. Can we still support a
mailing, an email type workflow while moving
to something else? That would be 1 of the big
ones. I think another thing that trips people
up is that we used a bug tracker that,
I mean, maybe some people,
I've heard people say it's archaic.
It's called Debugs. I think maybe Debugs gets
a bit of a bad rap. I think that bugs is a
good piece of software.
It wasn't developed in 2023.
I mean, that's much as clear.
It's a little bit older,
but it really is a workhorse of the Debian
project, which is obviously a project that's
developed in a very different way than Emacs
is. It's on a completely different scale,
of course, much bigger,
many more developers, and so on.
But I think the developers did a good job for
the time. But it might be showing its age,
perhaps, in places. Perhaps,
again, it's the email workflow.
And people see that as a little bit of a
threshold. It seems alien.
It's a little bit strange,
the types of workflows that you have there.
So we are seeing some limitations with that
box. And again, how do you report bugs?
Well, in a sense, it's easy.
You send an email to bug-gnu-emacs at gnu.org
and you copy in whatever you get from,
you know, report the EMAX bug or if you have,
you know, send mail set up locally,
just hit control C, control C and it's sent
to the bug tracker and that's fine.
But also I have to mention that there is this
very good package on GNU Elpas.
If you're ever trying to read the Emacs bug
tracker or following along in Emacs
development, I really recommend install the
package devbugs from GNU Elpa.
It's so good. And again,
it's built on GNU, it's all integrated in
Emacs, it's so much better than using the web
and so on. And if you really want to get into
it, you can download the bug tracker archives
and the mailing list archives,
and you can put them locally,
you can have them searchable,
and you can have whatever experience you
like. So, I mean, it's really a flexible
workflow, but it's a bit strange,
perhaps, to some people.
So we also think supporting only this
workflow might be a little bit too limiting.
So we do want to move over to something like
GitLab, perhaps Sourcehat or something
similar. We've had a couple of discussions
about that over the last couple of years.
I think even before that,
but that's how far back I've been involved,
and definitely it's come up occasionally.
I think we are less far away than perhaps
ever is how I would express that,
and in the sense that the remaining blockers
for just making the shift,
let's say, are I think,
I mean, first of all, we're talking about
limitations, perhaps in the software,
they're well defined, and they're not as
amountable. I don't think they have to be in
any case. We should be able to make some
progress. The main thing that we're lacking
now is not more discussion or more people
prodding us to just please switch over.
No, we're looking for volunteers.
If you think that you,
you know, have what it takes to sort of come
in and help us do something like that and
work together with us,
you know, to see what can be done,
perhaps some, a few things would need to be
changed in GitLab. I don't think anything
huge, but maybe there are some patches to be
written and sent upstream,
or maybe we need to do some local hacks or
whatever. If you wanna do that,
please contact us, emacsdevil.
We'll be very happy to talk to you.
And then we can start making progress.
So I'm really hoping that that sound like
will come into place. But we need to,
if we do switch over, we need to preserve the
good parts of our email-based workflows.
So there are requirements there so that we
can continue to do our job as maintainers,
if you like. Another thing is that we've
sometimes seen that there's a bit of a
different culture perhaps on mailing lists
and on Emacs devil than what many people are
used to, especially like you've used perhaps,
many people might be in university and
they've started using Emacs,
maybe got into a little bit of package
development and starting to get the ropes of
that and are very used to working on places
like GitLab or something like that,
then the type of culture and way of
communicating that we use in Emacs might be a
little bit different. And of course,
it's different in the sense that mailing
lists have always, I mean,
let's say hacker culture,
whatever you want to call it,
have always communicated in a particular way
using mailing lists. So it's like succinct to
the point, perhaps I'm skipping a few
pleasantries. And the idea is that you should
just use it in as effective way as possible,
so that also the archives are usable.
And the other thing is that generally people
involved in developing free software has to
deal with a lot of incoming traffic,
emails. They don't have the bandwidth if it's
too much noise. You really need to be strict
to keep the signal to noise ratio high.
We have some weird terminology on the Emacs
devil. People tell us,
we say sometimes install patches which
basically means push to master or merge pull
requests because we've used other version
control systems in the past where it might
have made more sense to say install patches.
And then you sort of, I don't know,
I say it. Don't ask me why.
But it feels natural after a while.
You install a patch. It's clear what you
mean. You don't have to worry about which
branch it's on. So it's a little bit
historical there. So there is some of that
culture going on. It might be different.
We don't use emojis that much.
That's another thing. There is no like,
you can click the little like button at the
bottom of a comment or an email as you could
on GitHub. But there are exceptions and it's
not like someone will send you angry emails
if you use an emoji or something like that.
But it can come off as perhaps Because people
are pressed for time also when replying to
all these emails. So it might come off as a
little bit short, but that's just how it is.
And I think We have heard this comment before
that mailing lists are scary or Emacs devil
is scary or core development is scary.
And I've touched a few of these points a
little bit already. I think,
yeah, maybe a little bit.
For example, we don't use emojis very short
in the communication. And we always use
correct grammar and spelling.
We take that seriously because it's important
for being clear in your written communication
when all you have is written communication.
It's really important.
But it's not like If you come in there and
you don't know all these cultural rules and
all these patterns, then you know you will We
won't talk to you No Actually,
we try to be as welcoming as we can and and
be mindful and you know people not Everyone
has English as their native language,
for example. So perhaps someone says
something, and it might come off as rude,
but maybe it's just a direct translation.
So we're trying to give a lot of whatever the
native language is. So we try to give a lot
of leeway and just be a little bit,
you know, flexible and focus on,
you know, the key, key points,
which are the technical things,
the technical decisions,
technical arguments, rather than,
you know, getting bogged down in a lot of,
you know, personal, you know,
discussions and flame wars.
So, I mean, there are these things to be
aware of, you know, it's just a little bit
different. I don't think it's anything huge.
And I wouldn't be, you know,
I think it would be sad if people felt too
intimidated by that. It just is what it is.
And if you spend some time there,
you'll see how people generally communicate.
Sometimes, there are a lot of people on
EmacsDevil. It's a public mailing list.
A lot of people just sign up to follow Emacs
development. Sometimes they chime in.
And I think this is in general a good thing.
I think it should be a public mailing list.
Sometimes this leads to weird situations from
just a point of view as an Emacs maintainer,
right? I mean, I try to say something and it
doesn't always say, oh,
he's the maintainer or whatever.
So when I say something,
it should carry a little bit more weight than
some unknown person from the internet who has
an opinion and decided to send it to
EmacsDevil. So it's good to be a little bit
aware of who is a little bit more involved
with the project. I would check out the
maintainers file. I would check,
see in the Git log, do these people actually
have any anything in core?
And if not, maybe, you know,
there, we won't really,
even if they express an opinion very
strongly, even if they're a little bit rude,
maybe they're not even involved in Emacs
development. I mean, often,
that's the case we have some people,
unfortunately, at times,
we have random people from the internet come
in on the mailing list and they're just a
little bit rude, or they say an opinion
that's not exactly helpful.
And I think you need to be aware.
I mean, these things happen in any forum,
but it happens on EmacsDevO as well.
So just be a little bit aware of who you're
talking to, what people are doing.
It can help to Check the archives,
see who writes what, and so on.
But it's not something that I think is a huge
problem. It is just, again,
something to be aware of.
We have the new kind of communication
guidelines in place, which basically says
that you should be nice to people and stay
focused on the technical problem,
try to see things from another person's point
of view, this kind of stuff.
So we're really trying to be as inclusive as
possible and just stay correct in general.
And sometimes, I mean,
not everyone, it's a public list.
We moderate it, but not to a huge extent,
right? So sometimes people get away with a
little bit of perhaps stretching the
boundaries of what might be included in the
kind communication guidelines,
sort of the fences and limitations of that.
But I would just ignore that.
Sometimes it happens that we,
as happens in any forum,
by the way, you just, we have these very big
threads. We start discussing something else.
Perhaps you send us a patch and it just
devolves into us discussing something
completely different. And of course I partake
in that, not better than anyone else,
but it just happens. I mean,
it's not your fault. It's just what happens
sometimes in forums, and don't mind that.
And it's a little bit easier to do that in
emails, because you just change the subject,
and now it's supposed to be a different
thread, but it comes as replies usually to
you, which wouldn't happen perhaps in a
different workflow. So it's something to be
aware of as well. Another thing is that,
of course, in written communication,
tone doesn't always come across.
If someone sounds negative,
sometimes it's just them being neutral.
Sometimes you get no replies.
You send something, you get no replies.
And this could mean, actually it could mean,
yeah, what you said was uncontroversial.
We think it was a good idea.
No 1 replied to it because either someone
else would reply or just there was no need to
reply because, yeah, why not?
So but if you do send a patch and you don't
get an answer, wait. I mean,
don't wait 1, 2 days. Maybe we're busy or
we're sick or whatever.
Wait 2 weeks. It's fine to just send it
again. If you send the patch to EmacsDevil,
send it to the bug mailing list,
because we lose track of stuff on EmacsDevil.
That's just the reality of it.
So if you propose making a change and no 1
commented, feel free to ask us again if a
patch would be welcome and we will clarify.
Bug reports, unfortunately,
if you get no answer, I mean,
we do have a limited amount of time to work
on bugs. If you're looking to get started in
Emacs development, this is an excellent way
to start getting involved.
What I'd recommend is start looking into
bugs. I'd install that bug,
I'd see about the mailing workflow and set
that up a little bit, or not.
It's up to you. You can reply to an email
without setting any of that stuff up.
But just help us try out your bugs,
send patches, do that type of stuff.
I mean, that's an excellent way,
and extremely welcome.
We're so happy to see when people pick up bug
reports that have been left by the wayside
and just fix them, send us a patch,
and we can just apply it.
So that's really your starting point if you
want to get involved in Emacs core
development. I also want to say that be aware
that you know Emacs is the editor of the GNU
operating system and this makes the project
political a little bit whether you like it or
not. Luckily the you know the politics are
limited enough that we can find broad
agreement on it. So we want to promote,
we want to create free software.
That's sort of it. That's it.
And there shouldn't be too much more to it,
right? We want to rid the world of
proprietary software as an evil thing.
Ideally, all software should be free.
But these are just the goals of the free
software movement. So we're very strict with
some things. We don't recommend non-free
proprietary software. Of course,
we have no problem mentioning Microsoft
Windows because everyone knows that there's
this obscure operating system developed in
California that some people insist on using.
We use, many of us use GNU plus Linux.
Actually, some core developers happen to use
exactly, you know, not GNU plus Linux,
but that's fine as well,
right? We take a little bit of a pragmatic
view, but we don't wanna do,
what we don't wanna do is promote like this
small, unknown piece of non-free software and
sort of help the non-free software in that
way. That's where we try to draw the line,
you know, in just expressing just a few
words. So that's 1 thing.
We're, I think, very pragmatic on this point,
but we do try to follow the principle.
We also require copyright assignment.
And I think in general,
the argument is that we require a copyright
assignment, because that makes it easier to
defend the legal status of the GNU Emacs
source code. So if there's ever a legal
battle, the idea is that if it's only 1
copyright holder and you have a GPL
violation, i.e. Someone might change Emacs
and then distribute it as proprietary
software or something nasty like that,
then we have an easier way of defending it in
court if there is only 1 copyright holder.
So we assigned copyright to the Free Software
Foundation. And I think there,
I mean, sometimes people oppose this for
various reasons, you know,
people see it as, you know,
maybe some people might say,
you know, it's ideological,
you know, who goes, you know,
the FSF goes too far with this.
And, and, I mean, that's fine.
You that's, that's an opinion.
And the there, then other people are more
practical, you know, it's just,
It's a hassle, basically,
we don't want to sign these papers.
And I'm not really here to tell anyone that
they're wrong. I've expressed my views on
this in the past. But just for now,
I'm just very practical for the purposes of
this talk. So I signed the papers.
It's Maybe it didn't take me many minutes.
And in most cases, it shouldn't really.
And it's something that I found worth doing,
because that way I could focus on continuing
to improve Emacs instead of discussing the
finer points of copyright law.
You could write patches and stuff,
that kind of thing. So,
I mean, this is something that trips people
up and, you know, it's fine that people have
different opinions on it and so on,
but I think for now that's just something to
be aware of. So that's,
I think, I mean, there's much more that could
be said. Ideally, I would like to have a
practical part to this talk as well.
But I wanted to say something about the
packages in Emacs. Because as we know,
I mean, Emacs is the, I can't remember what
it says, it's like a visual,
there's in the manual it says,
oh, Emacs is an advanced text editor.
It's visual, which, I mean,
it's not ed, the whole Unix ed,
so that's cool. It's also customizable,
right? So that's always been a thing.
And what makes Emacs so amazing.
And some people described it as,
I can't remember who said that there has been
a Cambrian explosion of packages in Emacs.
And I think that's true.
I mean, if you look at something like Melpa,
I think they have over 5,000
packages now. It's like truly impressive,
just an immense amount of work and immense
amount of packages. And really,
this shows the strength,
I think, of the Emacs community,
of Emacs itself as an idea.
And I think it's also just tremendous work
that's been done by the maintainers.
And they do get a lot of recognition for
that. And rightly so, in my opinion.
It's done so much, I think,
for our community. The other package archive
that we have is GNU-ELPA.
And that's been enabled since when packages
first got introduced back in,
I think, Emacs, was it 23?
And probably, I mean, the main thing why a
package goes onto GNU Elpa is,
you know, it should be installable out of the
box. So, I mean, that's a big benefit in a
sense. It's also a requirement for GNU Alpa
that the copyright, again,
just as GNU Emacs, the copyright is assigned
to the Free Software Foundation.
And some very hugely popular packages,
like YaSnippet, for example,
is on GNU Alpa. And we were discussing this
just 2 months back. And Joe Tavora,
I can't say his name, G-O-A-O,
Tavora. He made the point that he's never
seen a problem in any of his packages with
copyright assignment in particular.
It's never been a problem to get people to be
involved in the development of those packages
just because of the copyright assignment
requirements. So I mean,
that's his perspective on that.
And I think it was worth relating his
experience here. So we also have this new
package archive called non-GNU-alpha,
which is now enabled by default as well.
I think for practical purposes,
you could get into it a little bit more,
you know, why we created non-NUELPA,
and perhaps that's something we can discuss
in the Q&A section. For practical purposes,
the main thing to be aware of is,
yes, we don't promote non-free software on
there, And we also don't have the copyright
assignment requirement.
I think this is probably for new packages.
It's generally better if they go to GNU Elpa,
if there is any type of idea or ambition
that, you know, at some point it would be
good or it might be good to eventually have
some type of functionality like this shipped
with Emacs itself. So I think this is
something that perhaps package authors could
also be aware of, that occasionally we do
bring in functionality from GNU Elpa into
core Emacs because we feel that it should be
better integrated with Emacs itself.
So if I could give any type of
recommendation, of course,
you do. These are your packages,
right? In an ideal world,
we would only use this for legacy packages
where people contributed in the past,
but you didn't worry about the copyright
assignment. But where possible,
I think there is benefit in putting it on GNU
Elpa. And I wanted to end a little bit on a
more, you know, the more opinionated perhaps
part of my talk and not just talk about
processes. I see that I'm running out of
time. So I will say Emacs is hackable.
And I think that's a blessing and a curse.
And if you think about something like,
the types of choices that you can make,
perhaps when you implement something,
There are choices, different choices between
something like common list,
which is like bigger, more batteries
included, and something like scheme,
which is more minimal.
And I think we have some of those,
you know, this kind of tension also in the
Emacs itself. What should be in Emacs core?
Should we have a lean Emacs core?
Should we have more stuff in Emacs core?
And I think these are good discussions to
have. And there are various challenges that
are associated with each of those choices.
I think what will never change is that Emacs
is hackable. Emacs is customizable.
This is the key strength.
This is why we love and use Emacs.
I think fundamentally,
whether you do it a lot or not,
this is what at core is bringing you that
amazing user experience.
However, the flip side of that sometimes is
that it's so easy to hack Emacs so that we
hack around bugs instead of fixing them.
We do some tweak and our customers say,
okay, this is a little bit broken,
Let me just fix it. I'll put an advice on
this function. I'll do this customization.
Or we accept limitations in Emacs core.
And I think it's fine.
I mean, this will never change.
That will always be core to what Emacs is,
right? However, I think that the flip side of
that is that I think sometimes we could be
better at just taking those few extra steps
to also make Emacs better itself and solve
this for all users. And I think if we can
build a little bit more of a culture like
that, I mean, we already have that culture to
a large extent, don't get me wrong,
we do, but if we can get a little bit more of
that culture, let's get that into core,
let's get that problem fixed,
that frustration. I can tell you that,
I just started a new assignment at work,
I already told you, so I'm going to write a
lot of Python, okay? So I need to keep track
of something called virtual environments,
and that's just a way to install these
dependencies just locally per directory or
per repository kind of thing.
And I've used various packages for that.
There are like 4 packages,
5 packages, maybe. And 1 is called VM,
and 1 is called VirtualM,
and 1 is called Python-VM.
And now I'm using, you know,
I'm using a different 1.
And it's just a little bit,
why doesn't this work out of the box in
Emacs? Why? I don't think there's a really
good fundamental good reason why something
like that doesn't work in Emacs.
So I think that's really,
I mean, I'm sure there are other things like
that, other fundamental features.
Why is it that for the last 20 years,
we've shipped Emacs with no PHP support out
of the box? I mean, I'm not a PHP programmer.
I don't really have a lot of love for PHP,
let's say. To me, it's a very funny-looking
language, but okay, still it's been very
popular. Why haven't we supported it?
I mean, it's just strange.
You install Emacs on some machine,
you open a PHP file, you get fundamental
mode. It's not the best user experience,
in my opinion. So I think there are some
things where we really could do a little bit
better. And I'm seeing this all the time.
Just this week, this new assignment was
interesting. There was this Emacs user.
Turns out we have the exact same hack in both
of our init files. So we had created the
exact same mode for DIRED,
actually, to hide dot files.
You know, dot something is supposed to be
hidden on a Unix system.
So we had DERED hide dot files mode to just
hide them. And why isn't that in DERED?
Or should it be in DERED?
Should it be a package on the new Elpa?
Where should it be? Why is it just local
hack? Should it be on a wiki somewhere?
I mean, sometimes that's the correct answer.
Sometimes the correct answer is,
yes, it should be a package.
Sometimes the correct answer is,
yes, it should really be in core.
So what I want to promote is more like,
let's just take a step back and just ask
yourself, what's the best solution if we look
at the overall picture?
Should I hack this into my configuration?
In many cases, yes, that's the right thing to
do. We don't want to proliferate just random
solutions all over Emacs for no reason.
But sometimes we want to fix it once and for
all. We want to do that in core.
So you could send stuff like that to us as
patches or as packages.
And we can discuss a little bit about where
should we solve this? What's the right level
of abstraction? I'm seeing that I'm running
out of time. I had an Emacs wish list.
Maybe we can take more of that in the Q&A.
But I want to say, like,
in VS Code, you just start VS Code.
You open a Python file,
and you get, like, hey,
are you trying to use Python?
Click here, install Python.
You get all the nice things out of the box.
And my argument is, why can't we have more of
that in Emacs? I don't think it's necessarily
hard, but it does take a little bit of work.
The challenges here are more social,
I think, than technical.
And I think it's worth doing,
because it's not just Python.
It's just There are always these small things
where it just really should work,
and that would be a much better experience.
And then you could customize not that thing
that should just work,
but you could customize more fun and
exploratory things instead of people
reinventing the wheel over and over again.
So I'm very excited about what's happening in
Emacs. I think we should be proud of what
we've accomplished. It's so many things to
many different people,
an environment for hacking,
just a productivity system.
Other sees us as a different way of looking
at computing, you know,
the embodiment of the ideal of the Lisp
machine if you want to talk big words and
stuff like that. And of course,
Emacs are all those things and so many more.
And that's what makes Emacs so amazing.
And in some sense, we should be care that
people are satisfied with using lesser text
editors. How could they be happy running
that? I mean, I'm sure it's fine,
but it sure as hell isn't Emacs.
So don't we owe it to the world and to them
and to ourselves to make a great Emacs.
That will be my ending words.
And I hope to see you all in the Q&A.
Thank you all. And thank you so much,
Stefan. That was a wonderful presentation.
And I just want to give you the opportunity.
You said that you perhaps had,
Not the practical stuff,
but you wanted to do a demo or something like
this? What did you mention exactly?
Yeah, we didn't have time really.
Yes, I'm not sure. I didn't prepare anything
so that we can do it live.
But maybe for next time,
I will do a demo. Don't hold me to it.
Or someone else could.
That would be really amazing.
Right. Well, thank you,
Stéphane. You've been already into so much
detail of so many... So much of the intricacy
of the maintenance. And as someone who's been
95% of the time developing for Melpa,
I feel like this talk was very geared to a
lot of us who tend to experiment in this
Cambrian stage of Emacs evolution,
where we get to deploy a lot of creativity
whilst also feeling pretty agile in a way we
come up with solutions to problems.
But you've won me over with your discussion
about potentially moving some of this stuff
to core. And I think this particularly
resonated at the end with this tension that
you feel about problems that you encounter.
Do you fix them in Melpa?
Do you fix them in core?
Is it not something that is supposed to be an
option? I love this tension and it's
something that we've been exploring for the
last 3 edition of Emacs Cons.
It's really what is to be the interaction
between this pool of very clever developers
who are on Melpa but who are perhaps a little
bit afraid of joining Core and the wonderful
job that you do that, yes,
seems archaic from the outside,
but as you've been at length today in your
presentation, is actually just a better way
to work, a very pragmatic way to get a lot of
work done. So, thank you so much for your
presentation. Thank you,
Leo. So, we have about 12 minutes now to go
through as many questions as possible.
You have obviously had a lot of questions
throughout your presentation.
Do you have access to the pad,
or do you want me to share the question and
feed them to you? Yes,
could you start with sharing them?
I'll see if I can get it on my screen.
Sure, I'll do that. Please let me know if my
microphone is clipping because my OBS setup
sometimes is a little bit janky.
But I'm going to try to read the questions
for now. It's tipping,
I can hear you okay. Okay,
so bear with the clicking,
we'll switch as soon as possible to Stefan
reading the question, but I'll read the first
1. Can you tell us some about your,
can you tell us some more I assume,
about your background with Emacs development
and programming in general,
your professional work possibly?
Yeah, sure. Okay, I studied computer science
at university. I started programming on a
Commodore 64. I started with BASIC and then I
did a couple of versions of BASIC as a kid.
But then really things took off when I
started using GNU Linux.
I can't remember which year,
maybe it was early 2000,
something like that, late.
No, it must've been before that actually,
because I remember I was 14.
Yeah, okay, so let's say 1999,
1998, somewhere there around.
Then I started with Perl,
and I did Perl for a good long while.
I learned C++, I learned C,
I did all kinds of stuff,
and then I went to university,
computer science, and I've been working,
you know, in various roles.
Right now, I'm coding Python.
Up until last Friday, I was writing firmware
in C for a small microcontroller,
which is pretty different than writing
Python, that's for sure.
So yeah, so that's a little bit about me.
I got interested in free software,
you know, also at a very young age.
So, I mean, I've been following these,
you know, ideological discussions and
debates, read all this stuff by Richard
Stallman and so on and so forth.
But yeah, that's it. Great,
thank you. I'll move on to the next question.
You'll have to listen to me because if I
start sharing my screen again,
we're going to get some clicks.
So the question. Do you think that 1 day
there will be a native I'll start again,
sorry. Do you think that 1 day there will be
a native... I'll start again,
sorry. Do you think that 1 day there will be
a native graphical web browser in Emacs or is
it kind of against its philosophy and
architecture? So will we stick just with EWW
and EAF or similar workaround tricks?
So if, I don't know if people have seen,
there is a talk by, I think,
Perry Metzger, is that the name?
Sorry if I got the name wrong.
Perry Metzger, I think.
It's like, he marks a text editor for the
next 40 years. He makes an excellent point
there that 1 of the things that we need to do
is really get a proper HTML rendering in
Emacs. It's like a dream at this point.
No 1 is actively working on something like
that. I think that, you know,
there, first of all, you'd need to rewrite
the display engine. So that's a big job.
It is. I'm not saying,
you know, it can't be done,
but you need to start there.
Right? Second of all, you need to think
about, you know, with all the Emacs Lisp code
out there, is really assuming,
you know, 1 paradigm, which is that you have
a square, and basically you have columns and
you have rows, and everything is in there,
even images, is basically in a column,
you know, in a column on a row somewhere.
Whereas, you know, when you just start doing
the more web stuff and web rendering,
you already have like a seaplane.
You have different types of geometries that
are possible. And what does it mean to go to
the logical next line in that kind of sense?
I mean these types of things I'm not saying
it can't be done. I'm saying there are there
are definitely some challenges there It would
be amazing I mean, but we need someone with
you know, the inclination and talent I think
to work on that's a job posting if I've ever
had 1. So good luck to whoever's willing to
apply for this 1. I think it's a tough 1.
It is, yes. Go on. Okay,
do you happen to have the questions in front
of you? Can I just read them to you so that
you can also have a feedback in front of you?
Yes, I have the pad here.
Okay, cool. So I'll read the next question
and this way I don't have to worry too much
about me butchering every word in the
sentence. So, Emacs development and
communication still is very much focused on
email mailing lists. I like this,
but what do you think about introducing other
channels for talking to users,
like the Emacs project community could set up
a master on instance of its own,
for instance? I think from the point of view
of the Emacs core team,
we don't really have a lot of resources or
people inclined to be working on stuff like
that. But I mean, there is so much going on.
Emacs is a very, you know,
It's a big community, frankly,
right? So people working on emacs.com,
there are people in the IRC channel,
the emacs IRC channel,
there's the emacs subreddit.
And I mean, people are doing an incredible
job. And I think if people wanna do more
stuff like that, I mean,
Don't wait for Argo, just go for it.
Great. Moving on to the next question.
Sorry, I'm not commenting anymore because we
have so many questions and I'd love for you
to answer as many people as possible because
we have about 6 minutes technically,
but we can go perhaps a little bit over.
If you have the time, Stefan,
though. Yeah. Okay, great.
What are some features or packages you'd like
to see developed by the community?
We've already talked about the native HTTP
display, but do you have any others?
So, I mean, developed by the community,
it depends what you mean.
So do you mean sending stuff that people
could be working on in general?
I think for now, like let's say the roadmap,
I'll just give some of the things that I
think should happen right now and that I
would love for people to send patches for.
That's what I'm gonna be answering because
that's what I think I can answer.
Tree-sitter is a new thing,
right? Improving and working on new modes
for, you know, TreeSitter,
it's not very hard. I think many people get
into it and make sure to integrate them in
Emacs core. I think that would be,
I mean, on my wishlist.
The other thing that is that we've asked for
someone perhaps with a little bit more
experience, I think, but working on
refactoring capabilities in Emacs and a more
general framework, I think,
for that. There are probably many more ideas
that I could give people,
but those would be the 2 big ones,
I think, that are also very uncontroversial.
It's funny because for me,
I don't think refactoring would count as a
feature, but it's so vital to allowing
further features to be developed.
Otherwise, I remember the way Org Mode used
to be before we had Org Element and stuff
like this. It was really complicated to write
any kind of parsing stuff for it.
And now that we've got it,
it just opened up a world of possibility
where parsing an Org Mode file is just made
so much easier. So I think that's a wonderful
answer because it goes,
it's multi-layered as you would expect from
something that concerns the whole of Emacs.
Moving on to the next question.
What is the hardest decision being made
within Emacs dev for the last 3 years.
I'm not sure, is it the decision in the last
3 years or I'll let you interpret the
question however you want.
Okay, well, I'll say this.
I started in August and I haven't had any
really hard decisions so far.
So good news. Maybe Eli will have more for
the last 3 years. Keep it simple.
Thanks. Cool. Next question.
Any plans to integrate XWM into core?
Emacs is a really good Winters manager.
That's super cool. I think EXWM is cool.
I think they need to upgrade to Wayland
somehow and that's not clear yet,
but you know, we don't have any current plans
to integrate it, no. Right,
Next question. Do you think it is a good idea
to choose Org Mode for writing documentation
instead of tech info? I think that whatever
we do, it should be the people that are
working on the documentation that should make
that choice. Currently we have,
I think, Modus themes and Org Mode itself is
writing their documentation in Org Mode,
that's fine by me. It has some drawbacks,
it has some benefits, but most documentation
is still in tech info.
Maybe we'd need to replace that at some
point, I don't know. But for now,
that's what people know and use.
And if you find that as a barrier to
contribute to Emacs, I mean,
just really write it as plain text.
We'll be happy to help you with the markup.
It's a little bit, you know,
finicky and stuff like that.
Great. Thanks for that.
Next question. What do you plan to work on in
Emacs Core in the future?
I'm a little bit hesitant to reply to that.
Of course I have ideas.
Of course there are projects that I'm working
on. However, if I say it here,
I feel like, you know,
then you'll hold me to it later and come ask,
where is that feature?
So I'll just say there is plenty of stuff
that I'm working on, and if you want to know
some of the stuff that I have been working
on, check the Git log.
I think that's just really as much as I want
to say about that right now.
You've added folks to just look at the path
with the changelog and that's all you need.
All right, moving on to the next question.
What do you use Emacs for in your life other
than working on Emacs itself?
Oh shit. So the big thing is programming,
right? Now I work as a programmer.
But in general, I use org mode heavily.
I use it for all my writing.
I use it to write, prepare this talk.
I use it as a productivity system.
I use it for emails. I use it as an RSS
reader. I do most of my computing.
I also have Firefox. So it's like Emacs and
Firefox for some reason.
I do read documentation in Emacs as well in
you, but yeah. Great. I'm still,
I do very much the same thing with you.
Like You've described exactly what I do.
I work as a programmer,
I use Augment for a lot of stuff,
and I think that describes a whole lot of
people currently watching the stream.
Moving on to the next question.
What could we do in order to make Emacs more
attractive for younger users?
This is an amazing question and I feel wholly
unprepared to answer this.
Probably more introductory material aimed at
that age group. What do you mean by younger
users? You know what would be really cool if
you had an Emacs for kids project?
That would be amazing.
I'm not sure if that's what people are
thinking about, but yeah,
that's about what I can say for now.
Good question. It is a very good question,
like it comes back always to a key topic in
EmacsConf, which is, how do we get more
people to join us? Because it's a wonderful
community. And how do we onboard people who
are not programmers or people who are younger
than the average Joe coming in those
meetings? There's this Excellent article by
Paul Graham, I think, where he was describing
how they used Emacs as the sort of customer
service system. They built the customer
service system for the early days of Amazon
in Emacs Lisp. And then they switched and all
the employees were sad.
So definitely there's more stuff that could
be done in Emacs and be done better in Emacs.
So for sure, if people want to explore more
stuff like that, that's amazing.
Yeah. And for people who weren't around
earlier today, we've had a presentation about
how to get computer science students to use
Emacs and trying to provide as much
information and as much tutorial as needed
for them to understand what is the philosophy
behind Emacs and how it influences the way
you work and so forth.
So you might want to revisit this discussion.
And we also have plenty of talks talking
about this issue. And I can just add that I
think it's very important for us as a
community to just be enthusiastic to get more
people involved. Because I mean,
look, there's this meme where it's like,
I use Arch Linux, by the way,
I use Arch, by the way.
And for some reason, people using Arch keep
telling you that they're using Arch.
That's fine. Use whatever you want.
It's free software, I don't care.
I think if you look at Vim users,
they're very almost militant,
oh, we're Vim, and Vim is the thing.
And Emacs users sometimes,
and it's fine. We take a bit of a more
laid-back approach. We're like,
yeah, I use Emacs, you use Vim,
whatever. And that's fine.
I mean, that's the correct approach,
I think. You should respect what people want
to use. I don't care that people use VS Code
or whatever. I'm not going to use that
because it's too limiting.
It's not really a workable environment.
But I think it's OK to be enthusiastic.
I think it's okay to talk about that type of
enthusiasm and anything that can help
increase the enthusiasm around Emacs can only
help the longevity of Emacs.
I agree and that's also 1 of the key
objectives of EmacsConf.
It's about bringing a lot of amazing people
to come talk, like you,
about stuff that is very dear to you.
And it's very tangible how much you care,
all of you, about what you're presenting.
And it's amazing to put all of you people on
just 48 hours talking about all of this and
then creating so much content for people to
watch. And I think it's really helping the
enthusiasm to live on and to gather a little
more snow as it comes down.
Yeah, I watch you Max Conf every year.
I think it's a lot of fun.
Thank you. I'll take the compliment for
everyone else in the team.
We're going to go a little bit longer with
the Q&A because we still have a lot of
questions and if Stéphane is still willing to
answer, I'm still willing to not go too bad
to hear a lot more of it.
Yeah, for me it's fine.
I have time. Great. So I think I've done this
question. So, all right.
How are we going to make sure that a cool
idea is going to pass it through for the next
generation, let's say 20 years later,
the generation still have the good knowledge
we have today. Yeah, so I mean,
if you think about what does EMAX need to
have staying power, so in general,
they say, you know, if if when you start a
company, if you have a company for 1 year,
then in all likelihood,
you're going to have it for 2 years because,
you know, it's just so if you've had Emacs
for 4 years, I'm saying that we're going to
have Emacs for the next 4 years as well.
Just based on that, I'm not sure the logic
holds up, but you know,
how does Emacs stay relevant?
I think is the question.
Well, I think we need to continue working on
all the types of exploratory work that people
are doing in the community.
I think there is fundamental stuff that needs
to be done. I mean, if people want to work
on, you know, web rendering and Emacs,
maybe that's the next,
you know, revolutionary step that we need
that could, you know, really showcase what
Emacs, you know, as, you know,
an idea, even if not Emacs as a software
could be and, you know,
Because there is huge potential in the idea
as such. So maybe that's something.
But I mean, from the point of view of core
development, I think we need to just continue
working on the fundamental technologies.
1 thing that I would like to eventually see
is a better garbage collector.
We've talked about that for a long time,
but I mean, we need someone to do the job
really. It's not very easy.
It's very hard, actually.
So just continues working on stuff like that,
continue with the exploration,
continue using and being excited about Emacs.
I think that's the best guarantee that we
have. Yeah, and perhaps to echo something
that you said earlier,
the tools that you're using,
like the emails, they've been around forever,
they will be around forever.
This pragmatic stance on the tools that
you're using, they might look stayed from the
outside, but ultimately they are what permits
a sense of longevity to any kind of project
you embark upon. Also,
in a sense, I think that the expectations
might be changing in the sense that,
you know, when I started using GNU Linux,
you know what the first thing I did was,
because I couldn't get Xorg to run.
So the first thing you had to do was you had
to compile your own Linux kernel.
So you sit there and make manuconfig and
you'll like, try to read it and you've never
done anything like this before.
You know, I was just a kid.
I had never been at this kind of,
you know, whatever. So I had to start with
that. And then you have to write the X or
configuration file. And I had the patience
for that. But nowadays,
people have different expectations.
You just install something,
and it works. And we need to keep that in
mind as well. So that's why I keep pushing as
1 of my big things. We need to build a more
cohesive experience out of the box.
Of course, that can be customizable.
You shouldn't shoehorn anything in just for
the sake of it. But you could get some things
a little bit more for free.
And maybe some of us that have our own
configs and we've been doing this for you
know, 2, 05:10, even 20 years,
we could also see, you know,
from the point of view of a new user that
just installs VS Code and then they click,
yes I use Python, yes I use that,
and then it just automatically works.
You know what I mean? I mean,
then could we get closer to that perhaps a
little bit? I think that would also help.
Yeah, I think that's what we call the
configuration wizard. And we were talking
about this, I think, a couple of years ago at
EmacsConf. I can't remember if it was with
Adam in the chat. Adam,
I mean Alpha Papa, or if it was with Bastien,
but I remember the idea cropping off.
Like, it's either you get a tutorial for
Emacs, a proper tutorial,
or you get a wizard, or you get both,
and then all is right for the world.
But definitely cool ideas being evoked.
I'm gonna say I need to decree the time when
we finish because for me it is 11.15
p.m. And I think my co-organizers are also
willing to end the day and go rest because
we've got another day to go tomorrow.
So how about we take 3 minutes and 30 seconds
to try to answer a little bit more succinctly
the questions we've got left.
How does that sound, Stefan?
Sounds great. Cool, so I'll start reading the
questions then that we've got left.
So this 1 we've got. If you're willing to
discuss it, what do you think about the
recent controversy about use of CLLib in
Emacs call code? Am I willing to discuss
that? I have said my opinion on Emacs,
Devel, I think. And I think I understand,
I think, the viewpoints of both sides in that
discussion. It is true that some things,
I mean, we have to think about that.
There is a real problem,
I think, when we have 3 different APIs for
doing the same thing in Emacs.
And can we make that a little bit better?
I mean, perhaps we could,
right? So that's about as much as I'd like to
say. Fair enough. I would have also accepted
that CL loops are ugly to write and they
don't feel very lispy.
But I'll take your answer as well.
Yeah, some people think that.
I understand that position as well.
Right. Okay, next question.
When we find a bug in our Emacs,
do we need to try to replicate it on our side
version, on our SID version,
sorry, then update all the usual list package
we use, and if we succeed to replicate the
bug in this version, only then go to
development version 30 and do the same.
Then only ask for assistance in reporting the
bug we found. So I believe when they
encounter a bug, are people supposed to go to
master to pull main and just to make sure
that they are on the latest version.
Is this something that you require?
We don't require that,
but we do try to encourage you to reproduce
it on master if we think that it matters.
Yeah, so if you can, that's even better.
But if the bug is there in Emacs 29,
maybe we want to fix it in Emacs 29.2.
So the latest point release is also fine.
Bugs in Emacs 28 at this point,
like the previous major version,
we might ask you to try to reproduce it on
Emacs 29 because we're not planning more
releases of old major versions.
So that's the fundamental reason for that.
Great. Thank you for your answer.
All right. Moving on to the next question.
On branching off sub-threads,
I note that they are less visible compared to
starting a new thread in practice.
I am wondering if it is just my impression or
something devs also observe.
Yeah, it's true. That's correct.
I don't know what to do about it.
If you want more visibility,
I guess just start a new thread.
I don't know. I can only agree,
really. I concur. That's true.
Okay. Next question. What about rewriting
Emacs in Rust? Use Guile instead of Elisp.
Multi-threaded Emacs. Make Emacs prettier and
shiny. And of course, same defaults.
Just kidding. We are spoiled children because
you and Eli, Lars, and etc do an impressive
work. I live in Emacs since 2001.
Thanks. That was a good 1.
Sane defaults. Okay, Well,
thank you. Thanks for that comment.
That made me chuckle. Next question by the
same person, I assume.
The only downside I see with copyright
assignment is that 1 has to disclose their
real identity. Would it be a possibility to
assign a copyright under a nickname?
Yeah, you don't have to say a real name.
Just register some pseudonym.
The FSF does need your real name,
but that's kept private only.
So feel free to reach out to assign at
gnu.org and ask more about that.
Right. All right, next question.
Do you think it is possible to reach an
agreement on sane defaults for better
out-of-the-box experience?
Yeah, so your sane is not my sane
necessarily. So that's the fundamental
problem that we're discussing here.
I think it's a social,
not a technical problem.
We do change defaults sometimes,
but I mean, there is also some staying power.
So it's understandable that,
you know, it's, we can't just change them
willy nilly and then flip flop between,
you know, 1 or the other kind of thing.
So it does take a little bit more time.
But yeah, sure, we can.
We do change defaults at times.
But it's perhaps more slower than what some
people would prefer, for sure.
So that's, yeah. Right,
all right. We have 2 more questions.
So will XWidgets have a future?
Seeing the new bugs popping up in the latest
XWidget dev. Not sure if there was the rest
of the question, But on XWidgets,
can you tell us a little more?
I'm not really following now.
I mean, I'm not seeing a lot of development
on XWidgets currently.
Some people have done work in fixing up a few
bugs, but I think that feature really needs
more love. So I think we need,
you know, help is welcome,
patch is welcome. That's what I can say about
that. All right, and our final question of
the day. Have you voted for Emacs as the
software of the year on the Tuxes by Jupyter
Broadcasting? I did because Emacs 29 is
great. Thank you. Okay,
well, good job voting.
I didn't know, I don't know what Tuxy is on
Jupyter broadcasting, but look it up and go
vote. So I wish I could tell you,
I assume with Tux, it might be something
related to Linux, but that's as much as I can
say. All right, well, Stefan,
thank you so much for taking the time not
only to do a wonderful presentation,
but also for answering all the questions of
the community. Do you have anything else to
add? Just really thanks for all the questions
and thanks for staying.
It's been a long day, a long conference,
so thanks for staying and listening to my
talk as well. Really appreciate it.
Appreciate the good work you guys are doing
behind the scenes, organizing,
setting everything up.
And really humbled to be a part of this
community. So thank you all.
Well I can assure you that no 1 either in the
organization team or the people watching now
felt like it was tiring to stay and listen to
your answers. So thank you so much Stefan.