Back to the talks Previous by track: Emacs development updates Next by track: Top 10 ways Hyperbole amps up Emacs Track: General - Watch

Emacs core development: how it works

Stefan Kangas

Work in progress: main talk does not have captions (Volunteered: jchelary 2024-01-10)

This talk does not have captions yet. Would you like to help caption this talk? You may be able to start with these autogenerated captions.

Format: 68-min talk ; Q&A: BigBlueButton conference room
Status: Q&A to be extracted from the room recordings

Duration: 1:07:13 minutes

Description

  • Why it is fun and exciting to contribute to Emacs
    • We have easy bugs that anyone can fix, in random packages
    • And extremely hard ones for experts in things like garbage collection, and compilers
  • We are not scary, in fact working to build a welcoming culture.
  • The nature of a public list
    • Don't listen to random people being negative or hostile
    • No response is not necessarily a bad thing
  • Cultural aspects of emacs-devel vs GitHub
  • How to behave (be polite, etc.)
  • Email vs forge, help wanted.
  • Why copyright assignment
  • Plans for Emacs 30 (maybe) - needs coordinating with Eli

If I have more time, I'd like to cover more things, for example:

  • GNU ELPA vs NonGNU ELPA - why and how
    • Our plans for GNU ELPA going forward (bundle stuff in tarballs)
  • The future of Emacs: a vision

Basically, I want to do everything I can to inspire people to join core development and to lower the barrier to participating. In effect trying to work on "bridging the gap" that we have identified exists between emacs-devel and the community.

About the speaker:

Stefan Kangas is one of the Emacs core maintainers.

Discussion

Questions and answers

  • Q:Can you tell us some about your background with Emacs development and programming in general (your professional work possibly)?
    • A: studied CompSci at university.  started programming on a Commodore 64, then C, Perl, and so on
  • Q: Do you think that one 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?
    • A: Proper HTML rendering in Emacs is a dream right now
  • Q: Emacs development and communication still is very much focused on E-Mail mailing lists. I like this. But what do you think about introducing other channels for talking to users? E.g., the Emacs project/ community could set up a Mastodon instance of its own etc.
    • A:
  • Q: What are some features or packages you'd like to see developed by the community?
    • A: Some of the things that Stefan would like to see happen right now
      • treesitter: improving and working on new modes
      • refactoring capabilities in Emacs
  • Q: What is the hardest decision being made within Emacs-dev for last three years?
    • A:
  • Q: Any plans to integrate EXWM into core? Emacs is a really good WM.
    • A:
  • Q: Do you think it is a good idea to choose Org-mode for writing documentation instead of Texinfo?
    • A
  • Q: What do you plan to work on in Emacs core in the future?
    • A:
  • Q: What do you use Emacs for in your life, other than working on Emacs itself?
    • A: Programming, obviously (Stefan works as a programmer).  org-mode (including to prepare this talk), for productivity, rss reader, emails.
  • Q: What could we do in order to make Emacs more attractive for younger users?
    • A: 
  • Q: How are we going to make sure that the cool idea is going to pass it through for the next generation, let's say 20 years later, that generation still have the good knowledge we have today.
    • A:
  • Q: If you're willing to discuss it, what do you think about the recent controversy about use of cl-lib in Emacs core code?
    • A: Stefan's opinion is on emacs-devel.
  • Q: When we find a bug, in our emacs.... do we need to try to replicate it on the sid version (debian/sid=1:29.1+1-5 at ehe time of writing), then update all the usual lisp package we use... and if we succeed to replicate the bug in this version, only then go to the development version 30 and do the same ? Then only, ask for assistance in reporting the bug we found ("M-x report-emacs-bug"  will be sufficient ) ?
    • A: (Answering for Stefan, because information about how to report Emacs bugs is widely available, including in Emacs's own documentation: You should try to reproduce it on the latest released version of Emacs, with a clean Emacs configuration (i.e. "emacs -q"), before reporting.  And you should look for existing bug reports on the tracker.  If you have extra time, consider trying to reproduce it on the master branch or the branch for the next release as well.  And if you're sure you've found a bug, be sure to report it using "M-x report-emacs-bug" rather than just emailing emacs-devel about it.)
  • Q: 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.
    • A:
  • Q: What about rewriting emacs in Rust? Use guile instead of elisp? Multi-threaded emacs? Make emacs prettier and shiny? And of course, sane defaults! Just kidding. We are spoiled children because you and Eli, Lars, etc. do an impressive work. I live in Emacs since 2001. Thanks!
    • A:
  • Q: The only downside I see with copyright assignment is that one has to disclose their real identity. Would it be a possibility to assign copyright under a nickname?
    • A: (not the speaker) FSF said they can publish a pseudonym but need the actual identity in their paperwork, which will be presumably protected, but it's not totally anonymous.
      • (AFAIK from Bastien) The actual FSF assignee list is not public - I know that it is available to maintainers, but must not be shared.
  • Q:Do you think it is possible to reach an agreement on sane defaults for better out of the box experience?
    • A: It's more of a social problem than a technical problem (my sane defaults might not be yours).
  • Q:Will xwidgets have a future? Seeing the new bugs popping up in the latest xwidget dev.
    • A:
  • Q: Have you voted for Emacs as the software of the year on the Tuxies by Jupiter Broadcasting? I did, because Emacs 29 is great! Thank you! :-)

Notes

  • Cambrian explosion of packages (5000 packages in MELPA)
    • GNU ELPA <- generally better if someday it might be good to ship it with Emacs
    • João Távora (Eglot author): haven't seen a problem with copyright assignment
      • To be fair, it does happen in certain cases. But infrequently.
    • New package archive NonGNU ELPA is now enabled by default, no copyright assignment needed
  • Emacs is hackable. I think that's a blessing and a curse. The types of choices you can make when you implement... Different choices between things like Common Lisp and Scheme. I think we have that kind of tensions within Emacs. These are good discussions to have. I think what will never change is that Emacs is hackable. Emacs is customizable. This is what's bringing you that amazing user experience. The flip side is that it's easy to hack around bugs instead of fixing them. Or we accept limitations in Emacs core. I think we could get better at taking those few extra steps to make Emacs better for all users.
  • Thank you Stefan! That was all really cool! :D
  • thank you you guys it's fantastic
  • thank you guys to say you amazing is to not give you enough

Transcript (unedited)

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.

Questions or comments? Please e-mail emacsconf-org-private@gnu.org

Back to the talks Previous by track: Emacs development updates Next by track: Top 10 ways Hyperbole amps up Emacs Track: General - Watch