Back to the schedule
Previous: Day 2 opening remarks
Next: Powering-up Special Blocks

Emacs development update

John Wiegley

Download compressed .webm video (14.3M)
Download compressed .webm video (8.4M, highly compressed) View transcript

  • Actual start and end time (EST): Start 2020-11-29T09.12.40; End: 2020-11-29T09.17.51


There is xwidget webkit based browser built in Emacs but this is not trivial to install it, it is slow and many pages do not work at all. On the other hand, there are standalone Emacs like browsers e.g. "Nyxt" and "Qutebrowser" (This one I use and love, in theory this is Vim like browser but can be configured to be Emacs like). Having built in high performance browser (not dependent on EXWM) would be game changing feature for Emacs. Are there any plans to make such browser within the roadmap of Emacs development or maybe that would make sense to work together with either Nyxt or Qutebrowser communities to integrate their browsers natively in Emacs?

(karthink on IRC): Can't native compilation happen asynchronously after installing Emacs? (Including for files in site-lisp)


  • Cairo enabled by default in Emacs 28.
  • Native compilation will land soon (currently in another branch, needs libgccjit). About 2.5 times faster(?)
    • Downtime of native compilation: long time to compile Emacs.
    • Native compilation products specific to the machines.
  • Emacs 27.2 will be released soon.
  • Emacs 28 will have better emoji support 🎉 (within C code). No timeline for 28 currently.


Hello EmacsConf! This is John Wiegley, I'm one of the co-maintainers of Emacs along with Eli Zaretskii and Lars Ingebrigtsen, and I wanted to give you a technical update on what has been happening with the Emacs in the last year. So, specifically we have a few notes that I've gotten from a call with Eli, he's been in charge of directing most of the technical contributions on the mailing list and monitoring all the patches. So, I'm more here just as a messenger.

(00:33) He says that we have good progress and support for Cairo, this is going to be enabled by default in Emacs 28, and Cairo plus HarfBuzz is going to be the preferred rendering combination. So, Cairo support is not new, but in the past there were a lot of bugs in the code, and so it was made experimental. Most of those bugs have been fixed recently, and now it becomes the default in the next major version, which will enable several good features such as color emojis, if you're looking forward to those. Xft, as a result is deprecated. There are bugs not getting fixed in that code, it doesn't appear to be very well maintained. It was the most advanced font backend in Emacs before Cairo became dependable. So, now that we have a more a better maintained and available solution in Cairo, we're going to go from that, go from Xft to that.

(01:21) Native compilation in Lisp will also be landing soon. It's currently on a branch, but there are several people using it, they say, they're very impressed. It does require live GCC JIT to be installed for it to work, and this means you have to have GCC 10 installed. Execution of Emacs Lisp with native compilation on is about 2.5 times faster than the bytecode interpreter, we don't yet have any measurements on memory or how it affects resources besides CPU, so, we do look forward to having more numbers and analysis to see what the real impact of that is going to be, also, it may vary in compute advantage based on the type of workload that you're performing. A downside to the native compilation at the moment is that, it takes a long time to compile even when you're doing a 16 core build of Emacs, it can still take 15 minutes to compile Emacs and all of its Lisp code with this enabled. Also, this is going to have to happen on every user's machine because we cannot distribute the native compilation products, they are specific to the processor that you might be running on. So, the Emacs distribution will remain much as it is now, but if you want to have the benefits of natively compiled core Lisp files, you're going to have to spend that time and have GCC 10 available to get that compilation support.

(02:45) The GTK only build is being prepared for merging. What this does is, it throws away most of the other tool kits that Emacs was using and relies only on GTK, making Emacs much more of a GTK application than it has been. The main issue here is that we were abusing GTK in some ways that weren't really meant, and now we're going to be more of a first club…, GTK will be more of a first class citizen in the approach and the ways that we use it, and be using it in the ways that the GTK developers intended.

(03:21) There is going to be much more support for xt-mouse. So, xt-mouse allows you to use your mouse inside of a terminal window, which you could do before, but there were certain aspects such as menus that weren't supported. So, instead of having kind of partial support for mouse inside of an XTerm, with xt-mouse, you get full support. This is going to allow changes in the way that things can be bound, the ways that key bindings can…, the mouse events can be mapped to key bindings while in XTerms, and yeah, little by little this support is being extended even further, so we look forward to seeing that develop in the near term. Once this is merged by the way, also then Emacs will have mouse support in every one of its available configurations, which has not been true until now.

(04:12) Emacs 27 will be soon releasing 27.2, and the pretest for that should begin sometime soon after EmacsConf is done.

(04:20) And finally Emacs 28 is going to get better emoji support, right now emojis are registered internally within Emacs as symbols which works in some ways but does not support some of the special features of emojis such as different skin tones for the hand emoji or face emojis. In Emacs 28, emojis are going to have their own support within the C code, and then this is going to allow those types of variations and other emoji specific font setups.

(04:51) So, that is everything for Emacs in the future, I don't have a timeline for you on when 28 will be available, but 27 is going to keep improving until we're ready to get there. So, have fun with the rest of EmacsConf, and I hope to see you there, Bye.

Sunday, Nov 29 2020, ~ 9:13 AM - 9:30 AM EST
Sunday, Nov 29 2020, ~ 6:13 AM - 6:30 AM PST
Sunday, Nov 29 2020, ~ 2:13 PM - 2:30 PM UTC
Sunday, Nov 29 2020, ~ 3:13 PM - 3:30 PM CET
Sunday, Nov 29 2020, ~10:13 PM - 10:30 PM +08

Back to the schedule
Previous: Day 2 opening remarks
Next: Powering-up Special Blocks