path: root/2024/captions/emacsconf-2024-emacs30--emacs-30-highlights--philip-kaludercic--main.vtt

WEBVTT captioned by anush

NOTE Introduction

00:00:00.000 --> 00:00:06.119
Hello, and welcome to Emacs 30 Highlights at EmacsConf 2024.

00:00:06.120 --> 00:00:08.839
Before I begin, I'd like to thank the organizers

00:00:08.840 --> 00:00:11.799
and everyone involved for putting this all together.

00:00:11.800 --> 00:00:13.759
While this talk is being pre-recorded,

00:00:13.760 --> 00:00:15.239
my experience from the last few years

00:00:15.240 --> 00:00:19.159
assures me that it will be a great experience for everyone.

00:00:19.160 --> 00:00:21.359
My name is Philip Kaludercic.

00:00:21.360 --> 00:00:24.479
I am a core contributor and ELPA co-maintainer.

00:00:24.480 --> 00:00:26.079
I was honored when Sacha asked me

00:00:26.080 --> 00:00:28.359
to take over the slot for this year.

00:00:28.360 --> 00:00:29.879
In the past few iterations,

00:00:29.880 --> 00:00:32.199
John Wiegley has filled a similar presentation

00:00:32.200 --> 00:00:35.679
focusing on more general Emacs development updates.

00:00:35.680 --> 00:00:38.519
This year, I will specifically focus on

00:00:38.520 --> 00:00:41.919
highlight features from the upcoming Emacs 30 release,

00:00:41.920 --> 00:00:43.919
which might or might not have been released

00:00:43.920 --> 00:00:48.079
by the time you are seeing this.

00:00:48.080 --> 00:00:51.079
As you can imagine, everything new about Emacs

00:00:51.080 --> 00:00:55.059
can always be found in the Emacs NEWS file.

00:00:55.060 --> 00:00:57.079
Or, alternatively,

00:00:57.080 --> 00:01:01.919
if one doesn't want to read through the 3,000 lines here,

00:01:01.920 --> 00:01:05.279
one can also take a look at the Emacs FAQ

00:01:05.280 --> 00:01:07.999
and then go to the what's new about

00:01:08.000 --> 00:01:12.219
or what's different about Emacs 30 node.

00:01:12.220 --> 00:01:14.759
Next to these two official options,

00:01:14.760 --> 00:01:18.599
I also have a page on Emacs Wiki

00:01:18.600 --> 00:01:21.439
called EmacsThirtyHighlights,

00:01:21.440 --> 00:01:24.279
highlighting some of the interesting features

00:01:24.280 --> 00:01:28.439
with some context and suggestions on how to try them out.

00:01:28.440 --> 00:01:30.039
This is more of a collaborative effort.

00:01:30.040 --> 00:01:32.719
So if you see this and think something is missing,

00:01:32.720 --> 00:01:34.519
feel free to add it.

00:01:34.520 --> 00:01:36.839
So without further ado,

00:01:36.840 --> 00:01:41.759
let's begin taking a look at new features in Emacs 30.

NOTE Android

00:01:41.760 --> 00:01:44.679
The biggest one, and the one I want to mention first,

00:01:44.680 --> 00:01:49.039
is Android support, native Android support.

00:01:49.040 --> 00:01:51.879
As you can see here, Emacs has been ported

00:01:51.880 --> 00:01:53.639
to the Android operating system.

00:01:53.640 --> 00:01:56.479
What this means is that from Emacs 30 onwards,

00:01:56.480 --> 00:02:01.279
you can build Android to target Android devices natively

00:02:01.280 --> 00:02:06.759
and using a graphical interface.

00:02:06.760 --> 00:02:08.799
While it has been possible to run Emacs

00:02:08.800 --> 00:02:11.159
inside of terminal emulators on Android for a while,

00:02:11.160 --> 00:02:13.919
this actually means that you can use Emacs

00:02:13.920 --> 00:02:17.519
on an Android device, a phone or a tablet,

00:02:17.520 --> 00:02:20.959
and have all the usual advantages from GUI Emacs,

00:02:20.960 --> 00:02:23.479
such as the ability to bind all commands

00:02:23.480 --> 00:02:25.479
without having to worry about--

00:02:25.480 --> 00:02:27.279
all keys without having to worry

00:02:27.280 --> 00:02:29.359
about terminal compatibility issues,

00:02:29.360 --> 00:02:32.759
displaying images and multiple fonts

00:02:32.760 --> 00:02:35.359
on the same display of different sizes.

00:02:35.360 --> 00:02:37.279
I should have a recording

00:02:37.280 --> 00:02:42.199
of that somewhere here--here we are--

00:02:42.200 --> 00:02:44.439
which I made earlier on my phone,

00:02:44.440 --> 00:02:47.319
because I'm recording this on a laptop--

00:02:47.320 --> 00:02:50.479
where we can see how touch interaction works

00:02:50.480 --> 00:02:53.199
on an Android phone. I can switch between buffers.

00:02:53.200 --> 00:02:56.119
Here I've connected an external keyboard,

00:02:56.120 --> 00:02:58.559
opening the Emacs website.

00:02:58.560 --> 00:03:02.679
We have images that we can interact with.

00:03:02.680 --> 00:03:05.319
We could resize them if we wanted to

00:03:05.320 --> 00:03:07.559
with the image resizing commands.

00:03:07.560 --> 00:03:10.359
Pinch-to-zoom works, so it

00:03:10.360 --> 00:03:12.759
does realize what touchscreen interactions are.

00:03:12.760 --> 00:03:15.239
With an external mouse, and for example,

00:03:15.240 --> 00:03:17.799
enabling context menu mode,

00:03:17.800 --> 00:03:22.679
I can even pop up little interaction windows,

00:03:22.680 --> 00:03:27.239
which one you would usually also know from GUI Emacs.

00:03:27.240 --> 00:03:32.959
TUI Emacs actually also supports them since a while now.

00:03:32.960 --> 00:03:34.639
And in this case, I'm demonstrating

00:03:34.640 --> 00:03:35.999
how even the touchscreen events

00:03:36.000 --> 00:03:39.119
can be inspected using the usual help system,

00:03:39.120 --> 00:03:43.359
and how context-mode notices

00:03:43.360 --> 00:03:45.239
where we are and allows me to, for example,

00:03:45.240 --> 00:03:47.799
evaluate this specific region,

00:03:47.800 --> 00:03:49.079
which I've highlighted down there,

00:03:49.080 --> 00:03:58.319
binding a command to touch-screen-scroll. Yeah.

00:03:58.320 --> 00:04:00.479
One should note that these additions,

00:04:00.480 --> 00:04:02.359
for example touchscreen interaction,

00:04:02.360 --> 00:04:04.159
are not specific to Android,

00:04:04.160 --> 00:04:06.839
but they also are supported in other operating systems,

00:04:06.840 --> 00:04:12.279
such as Wayland and Xorg, which are not operating systems,

00:04:12.280 --> 00:04:15.279
and Windows, insofar as they have touchscreen,

00:04:15.280 --> 00:04:18.419
and devices have touchscreen support.

00:04:18.420 --> 00:04:21.239
One should mention, or I want to mention,

00:04:21.240 --> 00:04:24.039
that the main developer behind this feature, Po Lu,

00:04:24.040 --> 00:04:27.319
should be complimented for the additional effort he put

00:04:27.320 --> 00:04:30.979
into making sure that Emacs for Android

00:04:30.980 --> 00:04:33.719
can be built using only a free software toolchain,

00:04:33.720 --> 00:04:36.999
which is certainly not something one has come to expect

00:04:37.000 --> 00:04:40.759
from working on Android applications,

00:04:40.760 --> 00:04:43.839
as usually you have to agree to some terms and conditions

00:04:43.840 --> 00:04:46.479
for Google-specific software.

00:04:46.480 --> 00:04:49.639
Final note is that if you try and look for this online,

00:04:49.640 --> 00:04:52.119
there are APKs you can find,

00:04:52.120 --> 00:04:54.679
but some of them might be outdated.

00:04:54.680 --> 00:04:59.359
To the best of my knowledge, Po Lu has...

00:04:59.360 --> 00:05:02.399
Emacs 30 Android Sourceforge...

00:05:02.400 --> 00:05:06.759
He has set up some system where here in Sourceforge,

00:05:06.760 --> 00:05:12.799
there are regular and updated

00:05:12.800 --> 00:05:14.519
APK files which you can download

00:05:14.520 --> 00:05:17.039
to avoid having to build it yourself,

00:05:17.040 --> 00:05:18.559
testing out the newest version

00:05:18.560 --> 00:05:27.619
in case there are some bugs which you'd like to report.

00:05:27.620 --> 00:05:33.119
Which-key is a package which has now been moved

00:05:33.120 --> 00:05:34.719
from ELPA to the core.

00:05:34.720 --> 00:05:38.879
If you haven't heard of which-key before, the idea is,

00:05:38.880 --> 00:05:41.399
or the general pitch is that which-key

00:05:41.400 --> 00:05:45.279
is a additional documentation interface for Emacs

00:05:45.280 --> 00:05:49.639
for displaying various keys which you could input,

00:05:49.640 --> 00:05:53.479
or various keys and key maps

00:05:53.480 --> 00:05:55.479
that have been partially inputted.

00:05:55.480 --> 00:05:57.639
A better way to demonstrate this

00:05:57.640 --> 00:05:59.319
or to explain this is just to show it.

00:05:59.320 --> 00:06:03.519
If we enable the which-key mode--it's a global minor mode--

00:06:03.520 --> 00:06:06.399
then I can press, for example, C-x,

00:06:06.400 --> 00:06:08.719
which is a prefix for the C-x keymap.

00:06:08.720 --> 00:06:11.719
Then down here in the buffer, in this window down here,

00:06:11.720 --> 00:06:15.599
we see various commands which we could invoke

00:06:15.600 --> 00:06:17.919
and the keys to invoke them with.

00:06:17.920 --> 00:06:23.039
For example, if I wanted to say C-x i for insert-file,

00:06:23.040 --> 00:06:27.319
then I just have to press i to highlight it once again.

00:06:27.320 --> 00:06:32.559
It should be down here. Pressing i without having to repeat

00:06:32.560 --> 00:06:34.759
the entire key code again,

00:06:34.760 --> 00:06:37.719
the partial key code again, just works.

00:06:37.720 --> 00:06:41.679
This is different from the feature which Emacs has already,

00:06:41.680 --> 00:06:45.519
which is if you have input the partial keychord,

00:06:45.520 --> 00:06:47.039
you can press C-h

00:06:47.040 --> 00:06:50.959
and then a help buffer pops up with a listing

00:06:50.960 --> 00:06:54.159
of all keybindings that start with C-x.

00:06:54.160 --> 00:06:56.639
The information is the same, the presentation is different,

00:06:56.640 --> 00:06:59.159
because now if I wanted to do C-x i,

00:06:59.160 --> 00:07:03.319
I have to repeat the entire keychord again.

00:07:03.320 --> 00:07:09.479
So it's a matter of personal preference, which you prefer.

00:07:09.480 --> 00:07:12.519
This is more of a traditional static approach

00:07:12.520 --> 00:07:19.639
because I get a help buffer which I can search

00:07:19.640 --> 00:07:21.119
using usual key commands,

00:07:21.120 --> 00:07:28.159
while which-key is more of a transient and modern.

00:07:28.160 --> 00:07:31.299
Some might prefer that approach

00:07:31.300 --> 00:07:35.519
to solving the same problem.

00:07:35.520 --> 00:07:39.119
Also, don't forget to check out the customization group

00:07:39.120 --> 00:07:41.959
for which-key which has a number of options

00:07:41.960 --> 00:07:44.699
which you might or might not be interested in.

NOTE EditorConfig

00:07:44.700 --> 00:07:50.879
Next up, Emacs 30 has built-in EditorConfig support.

00:07:50.880 --> 00:07:53.679
If you have not heard of EditorConfig before,

00:07:53.680 --> 00:07:56.379
I believe I've linked to it down here somewhere.

00:07:56.380 --> 00:08:00.160
Ah, there it is, EditorConfig.

00:08:00.161 --> 00:08:05.260
This is a file format used to specify

00:08:05.261 --> 00:08:11.959
common formatting rules in an editor-agnostic way.

00:08:11.960 --> 00:08:16.319
You might compare it to .dir-locals.el files,

00:08:16.320 --> 00:08:19.159
which is a sort of an s-expression

00:08:19.160 --> 00:08:22.159
for setting file-local variables in Emacs.

00:08:22.160 --> 00:08:26.559
Of course, this is restricted to the common subset

00:08:26.560 --> 00:08:29.299
of what all editors should understand.

00:08:29.300 --> 00:08:31.839
For example, indentation styles,

00:08:31.840 --> 00:08:36.699
whether you prefer tabs or spaces,

00:08:36.700 --> 00:08:38.759
tab width, file encoding, and so on.

00:08:38.760 --> 00:08:43.959
So it's nothing too advanced, but it's something...

00:08:43.960 --> 00:08:48.559
It is a file format which one sees popping up more

00:08:48.560 --> 00:08:50.439
and more often in lots of projects

00:08:50.440 --> 00:08:53.479
which want to enforce a consistent indentation style

00:08:53.480 --> 00:08:56.639
or formatting rules for all editors in a project.

00:08:56.640 --> 00:09:00.159
Having this built in is certainly useful in Emacs.

00:09:00.160 --> 00:09:03.579
Though one should note that it's not enabled by default.

00:09:03.580 --> 00:09:11.039
You still have to enable the global minor mode,

00:09:11.040 --> 00:09:14.239
which is simply turning on this one option.

00:09:14.240 --> 00:09:15.599
Shouldn't be more than that,

00:09:15.600 --> 00:09:18.759
and then Emacs will respect the rules.

00:09:18.760 --> 00:09:22.999
If it finds a .editorconfig file in the project directory,

00:09:23.000 --> 00:09:25.319
then it will respect those rules

00:09:25.320 --> 00:09:30.239
without having to do anything else.

NOTE use-package integration with package-vc

00:09:30.240 --> 00:09:34.599
Next up, use-package integration with package-vc.

00:09:34.600 --> 00:09:36.519
For those not familiar with either of the two,

00:09:36.520 --> 00:09:38.119
or at least one of the two,

00:09:38.120 --> 00:09:41.079
use-package is a popular configuration macro.

00:09:41.080 --> 00:09:43.119
What it does is it allows

00:09:43.120 --> 00:09:46.274
users to declaratively specify packages

00:09:46.275 --> 00:09:48.879
they would like to have installed and configured

00:09:48.880 --> 00:09:51.539
in their configuration file,

00:09:51.540 --> 00:09:54.359
so that, for example, if you copy your init.el

00:09:54.360 --> 00:09:55.959
from one system to another,

00:09:55.960 --> 00:09:58.519
it could bootstrap the entire configuration,

00:09:58.520 --> 00:10:00.719
downloading all the packages you want

00:10:00.720 --> 00:10:02.239
without having to manually do this

00:10:02.240 --> 00:10:05.039
on every system you'd like to use.

00:10:05.040 --> 00:10:07.559
This allows configurations

00:10:07.560 --> 00:10:11.039
to be self-encapsulated and portable.

00:10:11.040 --> 00:10:15.959
package-vc is an extension of package.el,

00:10:15.960 --> 00:10:19.679
which allows installing packages from an alternative.

00:10:19.680 --> 00:10:22.279
Instead of using the standard way to install packages,

00:10:22.280 --> 00:10:26.239
which is just download tarball and unpack it,

00:10:26.240 --> 00:10:28.359
byte compile, and so on,

00:10:28.360 --> 00:10:32.759
it will fetch the files for a package

00:10:32.760 --> 00:10:35.279
directly from the source code repository

00:10:35.280 --> 00:10:37.239
and initialize it in such a way

00:10:37.240 --> 00:10:39.119
that package.el can work with it.

00:10:39.120 --> 00:10:44.319
So it's just a front-end for installing packages.

00:10:44.320 --> 00:10:46.519
Even though these two were added to Emacs 29,

00:10:46.520 --> 00:10:48.399
we didn't have the time to work on the

00:10:48.400 --> 00:10:52.639
use-package integration of package-vc into use-package,

00:10:52.640 --> 00:10:55.359
which has been changed now.

00:10:55.360 --> 00:11:00.119
What we have with Emacs 30 is that

00:11:00.120 --> 00:11:02.839
there is a :vc keyword for use-package

00:11:02.840 --> 00:11:05.319
with which we can instruct use-package

00:11:05.320 --> 00:11:10.760
to not download a package using tarball,

00:11:10.774 --> 00:11:12.519
but instead to fetch the source code

00:11:12.520 --> 00:11:13.799
from a source code repository.

00:11:13.800 --> 00:11:15.919
This is useful if you, for example,

00:11:15.920 --> 00:11:18.319
have packages which you yourself work on

00:11:18.320 --> 00:11:19.959
and know that you always want to have

00:11:19.960 --> 00:11:21.919
the development version of the package

00:11:21.920 --> 00:11:26.639
where you can directly commit changes you've made

00:11:26.640 --> 00:11:29.159
to the repository and push them upstream.

00:11:29.160 --> 00:11:32.399
Or, if you know that you want to contribute to a package,

00:11:32.400 --> 00:11:35.559
you can use package-vc to download the source code,

00:11:35.560 --> 00:11:37.319
have all the version control information,

00:11:37.320 --> 00:11:41.759
prepare a patch and send it upstream.

00:11:41.760 --> 00:11:44.119
In these examples here,

00:11:44.120 --> 00:11:49.119
the first example Lisp instructs package-vc

00:11:49.120 --> 00:11:52.959
to download the source code from a URL.

00:11:52.960 --> 00:11:55.119
So this is a git URL where it will download

00:11:55.120 --> 00:11:57.399
the source code from, and in this case,

00:11:57.400 --> 00:12:00.399
choose the newest checkout of the source code,

00:12:00.400 --> 00:12:05.680
not the latest release. Down here, we have another example.

00:12:05.060 --> 00:12:09.159
I prefer to consider the following example here.

00:12:09.160 --> 00:12:10.879
If we just had written this,

00:12:10.880 --> 00:12:13.159
then package-vc would use the metadata

00:12:13.160 --> 00:12:16.279
which an ELPA server provides

00:12:16.280 --> 00:12:19.799
to fetch the URL from the official repository of,

00:12:19.800 --> 00:12:22.839
in this case, BBDB, without having to...

00:12:22.840 --> 00:12:28.239
It would be more or less the same like this up here,

00:12:28.240 --> 00:12:32.639
with the simple difference that package-vc integration

00:12:32.640 --> 00:12:36.359
into use-package doesn't check out the latest commit,

00:12:36.360 --> 00:12:38.359
but the latest release,

00:12:38.360 --> 00:12:44.159
just to keep configurations more deterministic by default.

00:12:44.160 --> 00:12:47.879
Of course, if you prefer to use latest commit,

00:12:47.880 --> 00:12:52.439
you can use a package-vc install command

00:12:52.440 --> 00:12:54.879
or just update the package manually yourself,

00:12:54.880 --> 00:13:01.739
which you can use using package-vc-upgrade.

00:13:01.740 --> 00:13:04.319
Next, I'd like to focus on a few features

00:13:04.320 --> 00:13:07.740
which one might not necessarily realize directly,

00:13:07.741 --> 00:13:11.399
but will hopefully improve your experience with Emacs.

NOTE JSON

00:13:11.400 --> 00:13:15.119
First up in this list is a new JSON parser.

00:13:15.120 --> 00:13:21.399
Let's maybe show the source code for that one:

00:13:21.400 --> 00:13:39.319
not json.el, json.c. The history of JSON parsing in Emacs

00:13:39.320 --> 00:13:43.279
started with Emacs 23 with the addition of json.el.

00:13:43.280 --> 00:13:46.919
This was the file which we had just opened a moment ago.

00:13:46.920 --> 00:13:50.959
This is a JSON parser in Emacs Lisp.

00:13:50.960 --> 00:13:53.199
It's fine, it does the job, but it can get slow

00:13:53.200 --> 00:13:55.479
if we have a situation like where

00:13:55.480 --> 00:14:00.479
Eglot uses a LSP server to communicate with

00:14:00.480 --> 00:14:02.959
and the LSP server can get a bit chatty,

00:14:02.960 --> 00:14:05.479
sending a lot of JSON data,

00:14:05.480 --> 00:14:08.199
which all has to be parsed and garbage collected,

00:14:08.200 --> 00:14:10.199
which can slow down Emacs a bit.

00:14:10.200 --> 00:14:14.119
The situation was improved upon in Emacs 29

00:14:14.120 --> 00:14:17.959
when JSON parsing was added to the core.

00:14:17.960 --> 00:14:21.039
This was the json.c file, which we see on this side,

00:14:21.040 --> 00:14:23.279
the old version of the json.c file,

00:14:23.280 --> 00:14:27.119
which employed the Jansson library (it's the C library)

00:14:27.120 --> 00:14:33.159
for parsing and accelerating JSON parsing in Emacs.

00:14:33.160 --> 00:14:33.999
This was good enough,

00:14:34.000 --> 00:14:36.159
or it certainly improved the situation

00:14:36.160 --> 00:14:38.559
for a lot of LSP clients.

00:14:38.560 --> 00:14:45.479
But in Emacs 30, the situation has been improved once more

00:14:45.480 --> 00:14:50.359
with the addition of a JSON parser directly in Emacs.

00:14:50.360 --> 00:14:52.999
So instead of using an external library,

00:14:53.000 --> 00:14:57.719
there's a custom JSON parser written in C in the Emacs core,

00:14:57.720 --> 00:15:01.559
which directly generates Elisp objects.

00:15:01.560 --> 00:15:04.999
The advantage to this approach

00:15:05.000 --> 00:15:06.359
compared to the Jansson approach

00:15:06.360 --> 00:15:07.919
is that there's no intermediate format

00:15:07.920 --> 00:15:09.199
which has to be allocated

00:15:09.200 --> 00:15:11.559
and memory managed and freed again,

00:15:11.560 --> 00:15:19.479
which of course incurs an additional performance overhead.

00:15:19.480 --> 00:15:22.659
Next to this, there's also a custom serializer

00:15:22.660 --> 00:15:27.119
for JSON contents translating a JSON object into a string.

00:15:27.120 --> 00:15:30.279
... The consequence of this is that

00:15:30.280 --> 00:15:35.600
there is absolutely no dependency on Jansson anymore.

00:15:35.640 --> 00:15:38.559
This in turn means that now all Emacs users

00:15:38.560 --> 00:15:39.799
from Emacs 30 onwards

00:15:39.800 --> 00:15:43.119
can take advantage of this new JSON parser

00:15:43.120 --> 00:15:44.879
and don't have to worry about whether

00:15:44.880 --> 00:15:47.799
or not they have Jansson, this JSON parsing library,

00:15:47.800 --> 00:15:50.999
installed on their system or not when they want

00:15:51.000 --> 00:15:56.839
to take advantage of this accelerated JSON parsing.

NOTE Native compilation

00:15:56.840 --> 00:16:00.639
Next up, another behind-the-scenes feature

00:16:00.640 --> 00:16:04.559
is that if you build Emacs on your own from source,

00:16:04.560 --> 00:16:07.879
you might know that if you wanted

00:16:07.880 --> 00:16:09.559
to use native compilation,

00:16:09.560 --> 00:16:12.319
so the translation of Elisp bytecodes

00:16:12.320 --> 00:16:15.559
to whatever the native assembly

00:16:15.560 --> 00:16:19.319
or native instruction set is on your system,

00:16:19.320 --> 00:16:24.359
you have to specify with native compilation.

00:16:24.360 --> 00:16:25.879
when invoking the configure script,

00:16:25.880 --> 00:16:28.879
otherwise it would not have been enabled at all.

00:16:28.880 --> 00:16:34.119
With Emacs 30, this step is not necessary anymore.

00:16:34.120 --> 00:16:36.719
The configure script will automatically check

00:16:36.720 --> 00:16:41.759
if you have the libgccjit library installed on your system,

00:16:41.760 --> 00:16:42.879
and if that is so,

00:16:42.880 --> 00:16:45.999
then native compilation will be enabled by default.

00:16:46.000 --> 00:16:49.559
In other words, if you have an issue with native compilation

00:16:49.560 --> 00:16:52.799
or prefer not to use it for whatever reason,

00:16:52.800 --> 00:16:55.559
you now have to type --without-native-compilation

00:16:55.560 --> 00:16:58.199
when compiling Emacs to prevent this from happening.

00:16:58.200 --> 00:17:02.279
But native compilation was added in Emacs 28

00:17:02.280 --> 00:17:04.399
and has proven to be a very stable

00:17:04.400 --> 00:17:06.199
and useful feature for most people,

00:17:06.200 --> 00:17:10.199
so there's probably no reason to do this

00:17:10.200 --> 00:17:10.939
and you can just invoke the configure script

00:17:10.940 --> 00:17:16.239
with one argument less. Right, and I'd like to finish up

00:17:16.240 --> 00:17:19.399
with a few smaller features, a few smaller highlights.

00:17:19.400 --> 00:17:30.719
Maybe we can go back to the listing here. Here we have it.

NOTE Tree-sitter

00:17:30.720 --> 00:17:32.839
There are a few new major modes

00:17:32.840 --> 00:17:34.239
based on the tree-sitter library.

00:17:34.240 --> 00:17:37.739
tree-sitter is this parser library

00:17:37.740 --> 00:17:42.879
which has been integrated into Emacs 29.

00:17:42.880 --> 00:17:44.079
It allows the integration

00:17:44.080 --> 00:17:48.359
of external, specialized, and quick parsers into Emacs,

00:17:48.360 --> 00:17:52.119
which improve stuff like syntax highlighting, indentation,

00:17:52.120 --> 00:17:55.279
structural navigation, imenu support,

00:17:55.280 --> 00:18:00.839
by simply having a better understanding of, for example,

00:18:00.840 --> 00:18:03.919
a HTML file, or a Lua file, a PHP file,

00:18:03.920 --> 00:18:06.239
than what people usually implement

00:18:06.240 --> 00:18:10.319
using regular expressions in traditional major modes.

00:18:10.320 --> 00:18:16.819
So, a few new major modes which you can try out here.

NOTE Completion preview mode

00:18:16.820 --> 00:18:19.959
Another interesting feature is the completion-preview-mode.

00:18:19.960 --> 00:18:23.319
We can maybe try it out here in the scratch buffer.

00:18:23.320 --> 00:18:28.199
If I enable completion-preview-mode...

00:18:28.200 --> 00:18:32.719
This is a non-global minor mode,

00:18:32.720 --> 00:18:38.479
which will display completion options inline using overlays.

00:18:38.480 --> 00:18:43.199
For example, if I start typing a longer symbol like define,

00:18:43.200 --> 00:18:48.119
now we have a derived mode. It suggests me to...

00:18:48.120 --> 00:18:51.039
I can just press TAB and then it completes the option here,

00:18:51.040 --> 00:18:51.839
but it didn't actually...

00:18:51.840 --> 00:18:55.279
It's not actually modifying the buffer, it's not pressing,

00:18:55.280 --> 00:18:57.039
these are just overlays,

00:18:57.040 --> 00:18:59.519
so if I move around, it gets deleted.

00:18:59.520 --> 00:19:02.539
It wouldn't get saved if I were to save the buffer.

00:19:02.540 --> 00:19:04.999
The same also should work in a shell buffer.

00:19:05.000 --> 00:19:09.239
If I enable completion preview mode here and start...

00:19:09.240 --> 00:19:12.759
In this case, I'm using the bash completion package,

00:19:12.760 --> 00:19:15.199
which provides additional completion information.

00:19:15.200 --> 00:19:17.839
This is not only limited to programming systems,

00:19:17.840 --> 00:19:22.919
but anywhere where you have completion at point in Emacs.

00:19:22.920 --> 00:19:26.059
I can start typing here, ignore, and put ignore-backups,

00:19:26.060 --> 00:19:29.919
and it hints to the options which I have

00:19:29.920 --> 00:19:34.219
and allows me to complete them quickly.

NOTE package-isolate

00:19:34.220 --> 00:19:37.879
Another small feature is the package-isolate command.

00:19:37.880 --> 00:19:39.959
What this does is it will start

00:19:39.960 --> 00:19:42.759
or it will prompt me for packages

00:19:42.760 --> 00:19:44.119
I have installed in my system

00:19:44.120 --> 00:19:46.439
and will start an isolated

00:19:46.440 --> 00:19:51.079
or like "emacs -Q"-ish instance of emacs

00:19:51.080 --> 00:19:53.639
with only these packages installed.

00:19:53.640 --> 00:20:00.279
So for example, if I said I want slime and I want diff-hl,

00:20:00.280 --> 00:20:02.279
then this is a new Emacs window.

00:20:02.280 --> 00:20:04.439
It's unrelated to the one around.

00:20:04.440 --> 00:20:06.839
It uses the same executable, of course,

00:20:06.840 --> 00:20:09.939
but will not load your configuration file

00:20:09.940 --> 00:20:13.619
or any other further customizations on your system.

00:20:13.620 --> 00:20:15.159
All it does, it will ensure

00:20:15.160 --> 00:20:17.919
that these packages, which are listed here,

00:20:17.920 --> 00:20:24.499
so in our case SLIME and dependencies of SLIME and diff-hl,

00:20:24.500 --> 00:20:25.239
in the system

00:20:25.240 --> 00:20:29.039
so that I could, for example, as you can see here,

00:20:29.040 --> 00:20:31.959
diff-hl-mode works.

00:20:31.960 --> 00:20:35.479
Okay, this is not a version-controlled file.

00:20:35.480 --> 00:20:41.119
Maybe if we take a look at, have I enabled diff-hl-mode?

00:20:41.120 --> 00:20:44.559
It's enabled in this case. What diff-hl-mode does

00:20:44.560 --> 00:20:48.479
is it displays these version control changes

00:20:48.480 --> 00:20:49.999
in the fringe of a buffer.

00:20:50.000 --> 00:20:54.079
And even though this is a uncustomized version of Emacs,

00:20:54.080 --> 00:20:56.319
or an uncustomized instance of Emacs,

00:20:56.320 --> 00:20:58.959
it was easy for me to load this one package,

00:20:58.960 --> 00:21:01.959
or these two packages and all the dependencies necessary.

00:21:01.960 --> 00:21:05.319
As you can imagine, the main purpose for this

00:21:05.320 --> 00:21:07.719
is to make debugging issues easier.

00:21:07.720 --> 00:21:10.519
If you want to report about an issue

00:21:10.520 --> 00:21:14.519
you have with a package. And if I close this, it's closed

00:21:14.520 --> 00:21:16.779
and everything's thrown away.

NOTE Reindenting

00:21:16.780 --> 00:21:18.959
Last up, a nice feature I think

00:21:18.960 --> 00:21:21.199
a lot of people will appreciate is,

00:21:21.200 --> 00:21:24.239
if you are familiar with... Let's open a text buffer.

00:21:24.240 --> 00:21:30.079
The M-q key is traditionally bound to fill-paragraph.

00:21:30.080 --> 00:21:32.119
What this means is that...

00:21:32.120 --> 00:21:34.999
Let's, for example, copy this text from here

00:21:35.000 --> 00:21:40.359
and squash it all into one line. If I press M-q here,

00:21:40.360 --> 00:21:42.399
then the lines will be broken

00:21:42.400 --> 00:21:49.479
according to the fill column indicator up here.

00:21:49.480 --> 00:21:52.399
This is the traditional usage of M-q,

00:21:52.400 --> 00:21:54.119
and it still works in text-mode buffers,

00:21:54.120 --> 00:21:56.639
but in prog-mode buffers--

00:21:56.640 --> 00:22:00.079
so any major mode inheriting prog-mode--

00:22:00.080 --> 00:22:02.199
M-q will now by default be bound

00:22:02.200 --> 00:22:09.719
to prog-fill-reindent-defun. To summarize the point,

00:22:09.720 --> 00:22:13.479
if you are editing a string or a comment,

00:22:13.480 --> 00:22:15.919
then the comment will be filled.

00:22:15.920 --> 00:22:19.159
But if you are outside of a comment or outside of a string,

00:22:19.160 --> 00:22:22.919
then the defun or the top-level construct

00:22:22.920 --> 00:22:26.119
in the programming language will be re-indented.

00:22:26.120 --> 00:22:33.859
Let's try that out with maybe some file I have open here.

00:22:33.860 --> 00:22:38.819
If I'm in this... Let's choose some function,

00:22:38.820 --> 00:22:41.279
let's take this for example.

00:22:41.280 --> 00:22:43.879
If we followed all of this again,

00:22:43.880 --> 00:22:47.619
and I press M-q in on this paragraph,

00:22:47.620 --> 00:22:50.039
then the paragraph gets re-indented.

00:22:50.040 --> 00:22:54.859
But if I'm down here and I choose to break the indentation

00:22:54.860 --> 00:22:56.180
and then press M-q,

00:22:56.181 --> 00:23:02.399
then as you see, it practically selected the defun

00:23:02.400 --> 00:23:03.559
and re-indented everything

00:23:03.560 --> 00:23:05.959
without having need to move the point around in the buffer.

00:23:06.800 --> 00:23:08.679
So I think that's a really nice feature,

00:23:08.680 --> 00:23:11.039
which a lot of people can appreciate.

00:23:11.040 --> 00:23:17.879
It's one of those niceties which comes from time to time.

NOTE Wrapping up

00:23:17.880 --> 00:23:20.679
Right, so that was my overview

00:23:20.680 --> 00:23:22.559
of what's going to be new in Emacs 30.

00:23:22.560 --> 00:23:24.359
I hope that most people could take away

00:23:24.360 --> 00:23:25.659
something from this presentation

00:23:25.660 --> 00:23:29.419
and have something to look forward

00:23:29.420 --> 00:23:31.599
to try out after upgrading.

00:23:31.600 --> 00:23:33.839
As mentioned initially, as of recording,

00:23:33.840 --> 00:23:36.939
this release has not been completed yet.

00:23:36.940 --> 00:23:38.879
If this is still not the case

00:23:38.880 --> 00:23:40.199
when you're seeing this video,

00:23:40.200 --> 00:23:43.799
please consider downloading and building Emacs 30 yourself.

00:23:43.800 --> 00:23:48.319
If you have any issues, which is always the case,

00:23:48.320 --> 00:23:56.339
please report them to using report-emacs-bug.

00:23:56.340 --> 00:23:57.740
That will pop up a mail buffer,

00:23:57.741 --> 00:23:59.519
and then you can describe your issue and send them out.

00:23:59.520 --> 00:24:01.839
All bug reports are valuable,

00:24:01.840 --> 00:24:03.999
even if they are false positives or duplicates--

00:24:04.000 --> 00:24:05.239
it doesn't matter--

00:24:05.240 --> 00:24:08.919
because when you take the time to submit a bug report,

00:24:08.920 --> 00:24:12.359
which describes something that's specific to your setup,

00:24:12.360 --> 00:24:16.839
which the developers might not have noticed or known about,

00:24:16.840 --> 00:24:19.079
then you are certainly helping out a lot of other people

00:24:19.080 --> 00:24:21.679
which might run into the same issue in the future.

00:24:21.680 --> 00:24:23.359
Especially with upgrades,

00:24:23.360 --> 00:24:26.559
it would be nice to figure out small problems

00:24:26.560 --> 00:24:30.879
which make upgrading difficult for some people.

00:24:30.880 --> 00:24:34.559
The ideal is, of course, to have no issues

00:24:34.560 --> 00:24:37.199
when upgrading from one version to another.

00:24:37.200 --> 00:24:41.939
Having said that, I thank you for your attention,

00:24:41.940 --> 00:24:43.120
and I'm saying goodbye.