Hello, and welcome to Emacs 30 Highlights at EmacsConf 2024.
Before I begin, I'd like to thank the organizers
and everyone involved for putting this all together.
While this talk is being pre-recorded,
my experience from the last few years
assures me that it will be a great experience for everyone.
My name is Philip Kaludercic.
I am a core contributor and ELPA co-maintainer.
I was honored when Sacha asked me
to take over the slot for this year.
In the past few iterations,
John Wiegley has filled a similar presentation
focusing on more general Emacs development updates.
This year, I will specifically focus on
highlight features from the upcoming Emacs 30 release,
which might or might not have been released
by the time you are seeing this.
As you can imagine, everything new about Emacs
can always be found in the Emacs NEWS file.
Or, alternatively,
if one doesn't want to read through the 3,000 lines here,
one can also take a look at the Emacs FAQ
and then go to the what's new about
or what's different about Emacs 30 node.
Next to these two official options,
I also have a page on Emacs Wiki
called EmacsThirtyHighlights,
highlighting some of the interesting features
with some context and suggestions on how to try them out.
This is more of a collaborative effort.
So if you see this and think something is missing,
feel free to add it.
So without further ado,
let's begin taking a look at new features in Emacs 30.
The biggest one, and the one I want to mention first,
is Android support, native Android support.
As you can see here, Emacs has been ported
to the Android operating system.
What this means is that from Emacs 30 onwards,
you can build Android to target Android devices natively
and using a graphical interface.
While it has been possible to run Emacs
inside of terminal emulators on Android for a while,
this actually means that you can use Emacs
on an Android device, a phone or a tablet,
and have all the usual advantages from GUI Emacs,
such as the ability to bind all commands
without having to worry about--
all keys without having to worry
about terminal compatibility issues,
displaying images and multiple fonts
on the same display of different sizes.
I should have a recording
of that somewhere here--here we are--
which I made earlier on my phone,
because I'm recording this on a laptop--
where we can see how touch interaction works
on an Android phone. I can switch between buffers.
Here I've connected an external keyboard,
opening the Emacs website.
We have images that we can interact with.
We could resize them if we wanted to
with the image resizing commands.
Pinch-to-zoom works, so it
does realize what touchscreen interactions are.
With an external mouse, and for example,
enabling context menu mode,
I can even pop up little interaction windows,
which one you would usually also know from GUI Emacs.
TUI Emacs actually also supports them since a while now.
And in this case, I'm demonstrating
how even the touchscreen events
can be inspected using the usual help system,
and how context-mode notices
where we are and allows me to, for example,
evaluate this specific region,
which I've highlighted down there,
binding a command to touch-screen-scroll. Yeah.
One should note that these additions,
for example touchscreen interaction,
are not specific to Android,
but they also are supported in other operating systems,
such as Wayland and Xorg, which are not operating systems,
and Windows, insofar as they have touchscreen,
and devices have touchscreen support.
One should mention, or I want to mention,
that the main developer behind this feature, Po Lu,
should be complimented for the additional effort he put
into making sure that Emacs for Android
can be built using only a free software toolchain,
which is certainly not something one has come to expect
from working on Android applications,
as usually you have to agree to some terms and conditions
for Google-specific software.
Final note is that if you try and look for this online,
there are APKs you can find,
but some of them might be outdated.
To the best of my knowledge, Po Lu has...
Emacs 30 Android Sourceforge...
He has set up some system where here in Sourceforge,
there are regular and updated
APK files which you can download
to avoid having to build it yourself,
testing out the newest version
in case there are some bugs which you'd like to report.
Which-key is a package which has now been moved
from ELPA to the core.
If you haven't heard of which-key before, the idea is,
or the general pitch is that which-key
is a additional documentation interface for Emacs
for displaying various keys which you could input,
or various keys and key maps
that have been partially inputted.
A better way to demonstrate this
or to explain this is just to show it.
If we enable the which-key mode--it's a global minor mode--
then I can press, for example, C-x,
which is a prefix for the C-x keymap.
Then down here in the buffer, in this window down here,
we see various commands which we could invoke
and the keys to invoke them with.
For example, if I wanted to say C-x i for insert-file,
then I just have to press i to highlight it once again.
It should be down here. Pressing i without having to repeat
the entire key code again,
the partial key code again, just works.
This is different from the feature which Emacs has already,
which is if you have input the partial keychord,
you can press C-h
and then a help buffer pops up with a listing
of all keybindings that start with C-x.
The information is the same, the presentation is different,
because now if I wanted to do C-x i,
I have to repeat the entire keychord again.
So it's a matter of personal preference, which you prefer.
This is more of a traditional static approach
because I get a help buffer which I can search
using usual key commands,
while which-key is more of a transient and modern.
Some might prefer that approach
to solving the same problem.
Also, don't forget to check out the customization group
for which-key which has a number of options
which you might or might not be interested in.
Next up, Emacs 30 has built-in EditorConfig support.
If you have not heard of EditorConfig before,
I believe I've linked to it down here somewhere.
Ah, there it is, EditorConfig.
This is a file format used to specify
common formatting rules in an editor-agnostic way.
You might compare it to .dir-locals.el files,
which is a sort of an s-expression
for setting file-local variables in Emacs.
Of course, this is restricted to the common subset
of what all editors should understand.
For example, indentation styles,
whether you prefer tabs or spaces,
tab width, file encoding, and so on.
So it's nothing too advanced, but it's something...
It is a file format which one sees popping up more
and more often in lots of projects
which want to enforce a consistent indentation style
or formatting rules for all editors in a project.
Having this built in is certainly useful in Emacs.
Though one should note that it's not enabled by default.
You still have to enable the global minor mode,
which is simply turning on this one option.
Shouldn't be more than that,
and then Emacs will respect the rules.
If it finds a .editorconfig file in the project directory,
then it will respect those rules
without having to do anything else.
Next up, use-package integration with package-vc.
For those not familiar with either of the two,
or at least one of the two,
use-package is a popular configuration macro.
What it does is it allows
users to declaratively specify packages
they would like to have installed and configured
in their configuration file,
so that, for example, if you copy your init.el
from one system to another,
it could bootstrap the entire configuration,
downloading all the packages you want
without having to manually do this
on every system you'd like to use.
This allows configurations
to be self-encapsulated and portable.
package-vc is an extension of package.el,
which allows installing packages from an alternative.
Instead of using the standard way to install packages,
which is just download tarball and unpack it,
byte compile, and so on,
it will fetch the files for a package
directly from the source code repository
and initialize it in such a way
that package.el can work with it.
So it's just a front-end for installing packages.
Even though these two were added to Emacs 29,
we didn't have the time to work on the
use-package integration of package-vc into use-package,
which has been changed now.
What we have with Emacs 30 is that
there is a :vc keyword for use-package
with which we can instruct use-package
to not download a package using tarball,
but instead to fetch the source code
from a source code repository.
This is useful if you, for example,
have packages which you yourself work on
and know that you always want to have
the development version of the package
where you can directly commit changes you've made
to the repository and push them upstream.
Or, if you know that you want to contribute to a package,
you can use package-vc to download the source code,
have all the version control information,
prepare a patch and send it upstream.
In these examples here,
the first example Lisp instructs package-vc
to download the source code from a URL.
So this is a git URL where it will download
the source code from, and in this case,
choose the newest checkout of the source code,
not the latest release. Down here, we have another example.
I prefer to consider the following example here.
If we just had written this,
then package-vc would use the metadata
which an ELPA server provides
to fetch the URL from the official repository of,
in this case, BBDB, without having to...
It would be more or less the same like this up here,
with the simple difference that package-vc integration
into use-package doesn't check out the latest commit,
but the latest release,
just to keep configurations more deterministic by default.
Of course, if you prefer to use latest commit,
you can use a package-vc install command
or just update the package manually yourself,
which you can use using package-vc-upgrade.
Next, I'd like to focus on a few features
which one might not necessarily realize directly,
but will hopefully improve your experience with Emacs.
First up in this list is a new JSON parser.
Let's maybe show the source code for that one:
not json.el, json.c. The history of JSON parsing in Emacs
started with Emacs 23 with the addition of json.el.
This was the file which we had just opened a moment ago.
This is a JSON parser in Emacs Lisp.
It's fine, it does the job, but it can get slow
if we have a situation like where
Eglot uses a LSP server to communicate with
and the LSP server can get a bit chatty,
sending a lot of JSON data,
which all has to be parsed and garbage collected,
which can slow down Emacs a bit.
The situation was improved upon in Emacs 29
when JSON parsing was added to the core.
This was the json.c file, which we see on this side,
the old version of the json.c file,
which employed the Jansson library (it's the C library)
for parsing and accelerating JSON parsing in Emacs.
This was good enough,
or it certainly improved the situation
for a lot of LSP clients.
But in Emacs 30, the situation has been improved once more
with the addition of a JSON parser directly in Emacs.
So instead of using an external library,
there's a custom JSON parser written in C in the Emacs core,
which directly generates Elisp objects.
The advantage to this approach
compared to the Jansson approach
is that there's no intermediate format
which has to be allocated
and memory managed and freed again,
which of course incurs an additional performance overhead.
Next to this, there's also a custom serializer
for JSON contents translating a JSON object into a string.
... The consequence of this is that
there is absolutely no dependency on Jansson anymore.
This in turn means that now all Emacs users
from Emacs 30 onwards
can take advantage of this new JSON parser
and don't have to worry about whether
or not they have Jansson, this JSON parsing library,
installed on their system or not when they want
to take advantage of this accelerated JSON parsing.
Next up, another behind-the-scenes feature
is that if you build Emacs on your own from source,
you might know that if you wanted
to use native compilation,
so the translation of Elisp bytecodes
to whatever the native assembly
or native instruction set is on your system,
you have to specify with native compilation.
when invoking the configure script,
otherwise it would not have been enabled at all.
With Emacs 30, this step is not necessary anymore.
The configure script will automatically check
if you have the libgccjit library installed on your system,
and if that is so,
then native compilation will be enabled by default.
In other words, if you have an issue with native compilation
or prefer not to use it for whatever reason,
you now have to type --without-native-compilation
when compiling Emacs to prevent this from happening.
But native compilation was added in Emacs 28
and has proven to be a very stable
and useful feature for most people,
so there's probably no reason to do this
and you can just invoke the configure script
with one argument less. Right, and I'd like to finish up
with a few smaller features, a few smaller highlights.
Maybe we can go back to the listing here. Here we have it.
There are a few new major modes
based on the tree-sitter library.
tree-sitter is this parser library
which has been integrated into Emacs 29.
It allows the integration
of external, specialized, and quick parsers into Emacs,
which improve stuff like syntax highlighting, indentation,
structural navigation, imenu support,
by simply having a better understanding of, for example,
a HTML file, or a Lua file, a PHP file,
than what people usually implement
using regular expressions in traditional major modes.
So, a few new major modes which you can try out here.
Another interesting feature is the completion-preview-mode.
We can maybe try it out here in the scratch buffer.
If I enable completion-preview-mode...
This is a non-global minor mode,
which will display completion options inline using overlays.
For example, if I start typing a longer symbol like define,
now we have a derived mode. It suggests me to...
I can just press TAB and then it completes the option here,
but it didn't actually...
It's not actually modifying the buffer, it's not pressing,
these are just overlays,
so if I move around, it gets deleted.
It wouldn't get saved if I were to save the buffer.
The same also should work in a shell buffer.
If I enable completion preview mode here and start...
In this case, I'm using the bash completion package,
which provides additional completion information.
This is not only limited to programming systems,
but anywhere where you have completion at point in Emacs.
I can start typing here, ignore, and put ignore-backups,
and it hints to the options which I have
and allows me to complete them quickly.
Another small feature is the package-isolate command.
What this does is it will start
or it will prompt me for packages
I have installed in my system
and will start an isolated
or like "emacs -Q"-ish instance of emacs
with only these packages installed.
So for example, if I said I want slime and I want diff-hl,
then this is a new Emacs window.
It's unrelated to the one around.
It uses the same executable, of course,
but will not load your configuration file
or any other further customizations on your system.
All it does, it will ensure
that these packages, which are listed here,
so in our case SLIME and dependencies of SLIME and diff-hl,
in the system
so that I could, for example, as you can see here,
diff-hl-mode works.
Okay, this is not a version-controlled file.
Maybe if we take a look at, have I enabled diff-hl-mode?
It's enabled in this case. What diff-hl-mode does
is it displays these version control changes
in the fringe of a buffer.
And even though this is a uncustomized version of Emacs,
or an uncustomized instance of Emacs,
it was easy for me to load this one package,
or these two packages and all the dependencies necessary.
As you can imagine, the main purpose for this
is to make debugging issues easier.
If you want to report about an issue
you have with a package. And if I close this, it's closed
and everything's thrown away.
Last up, a nice feature I think
a lot of people will appreciate is,
if you are familiar with... Let's open a text buffer.
The M-q key is traditionally bound to fill-paragraph.
What this means is that...
Let's, for example, copy this text from here
and squash it all into one line. If I press M-q here,
then the lines will be broken
according to the fill column indicator up here.
This is the traditional usage of M-q,
and it still works in text-mode buffers,
but in prog-mode buffers--
so any major mode inheriting prog-mode--
M-q will now by default be bound
to prog-fill-reindent-defun. To summarize the point,
if you are editing a string or a comment,
then the comment will be filled.
But if you are outside of a comment or outside of a string,
then the defun or the top-level construct
in the programming language will be re-indented.
Let's try that out with maybe some file I have open here.
If I'm in this... Let's choose some function,
let's take this for example.
If we followed all of this again,
and I press M-q in on this paragraph,
then the paragraph gets re-indented.
But if I'm down here and I choose to break the indentation
and then press M-q,
then as you see, it practically selected the defun
and re-indented everything
without having me to move the point around in the buffer.
So I think that's a really nice feature,
which a lot of people can appreciate.
It's one of those niceties which comes from time to time.
Right, so that was my overview
of what's going to be new in Emacs 30.
I hope that most people could take away
something from this presentation
and have something to look forward
to try out after upgrading.
As mentioned initially, as of recording,
this release has not been completed yet.
If this is still not the case
when you're seeing this video,
please consider downloading and building Emacs 30 yourself.
If you have any issues, which is always the case,
please report them to using report-emacs-bug.
That will pop up a mail buffer,
and then you can describe your issue and send them out.
All bug reports are valuable,
even if they are false positives or duplicates--
it doesn't matter--
because when you take the time to submit a bug report,
which describes something that's specific to your setup,
which the developers might not have noticed or known about,
then you are certainly helping out a lot of other people
which might run into the same issue in the future.
Especially with upgrades,
it would be nice to figure out small problems
which make upgrading difficult for some people.
The ideal is, of course, to have no issues
when upgrading from one version to another.
Having said that, I thank you for your attention,
and I'm saying goodbye.