Emacs new features: native code and PGTK
I try to keep track of improvements in the projects I depend on the most, and sometimes I even track their development with the hopes of being able to contribute something back. One of such projects (though contributing back directly is pretty unlikely so far) is Emacs, and I build it locally to get the big improvements early on.
I started doing this with Emacs 27, when it was in pre-release state, because it added native JSON parsing. The parsing of JSON in Emacs was mostly done with Elisp at first, which could make Emacs quite unresponsive when processing large amounts of JSON, as LSP (Language Server Protocol) does all the time. From then, I usually browse the mailing list archives a couple times a month and keep an eye on interesting developments and proposals.
At the beginning of December we got the first pre-test release of Emacs 281 which includes native compilation2. Native Compilation is a new feature that uses libgccjit to compile ELisp code into native code so execution is faster. This is optional, but also enforces some practices that may lead to better quality code in ELisp packages, and mainly give a performance boost for ELisp heavy code. I do not have a benchmark, but I certainly felt a change in my setup when I started using an Emacs built with it. And I got no problems so far and few have been reported to the mailing list.
The other interesting merge was also around for a long while and got merged on December 18th: PGTK3. The branch for Emacs 28 was cut in September, so PGTK will be part of Emacs 29 instead. PGTK stands for Pure GTK and is a new GTK3 backend for Emacs reworking how the graphics side of Emacs works. Much has been written in the past about Emacs’ relation to the graphical UI toolkits4 and PGTK tries to improve that.
The degree of success of the PGTK backend is something still to be seen. My anecdotal report is that Emacs would crash frequently for me, sometimes even after a couple hours of work due to old and known bug affecting GTK5 (and some other issues most likely). While the other issues still make my Emacs crash from time to time, PGTK proved to be much more stable for me out of the box, with mixing degrees of success as it kept being maintained as a feature branch. I’m currently running the development Emacs after PGTK was merged and I still did not have issues (but also had few work done there due to the holidays) and I hope it will be more stable from now on.
Another benefit of PGTK is that it is compatible with Wayland which I use mainly, so many issues of the interaction between X and Wayland applications get resolved immediately with this option.
I love seeing the effort and care taken by a large part of the Emacs community into moving the project forward and helping it improve. This venerable editor is getting a lot of love in recent years, much like the NeoVim community has been giving to Vim. I sincerely thank all the people involved in these efforts and all those having civil and productive conversations to make improvements to this editor.