+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:45.879 which might or might not have been released
+00:00:45.880 --> 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.519 can always be found in the Emacs NEWS file.
+00:00:55.520 --> 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:10.079 or what's different about Emacs 30 node.
+00:01:10.080 --> 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:20.439 called EmacsThirtyHighlights,
+00:01:20.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.399 While it has been possible to run Emacs
+00:02:08.400 --> 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:23.079 I can even pop up little interaction windows,
+00:03:23.080 --> 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:17.319 and devices have touchscreen support.
+00:04:17.320 --> 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:29.759 into making sure that Emacs for Android
+00:04:29.760 --> 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:10.159 there are regular and updated
+00:05:10.160 --> 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:30.639 in case there are some bugs which you'd like to report.
+00:05:30.640 --> 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:52.679 or various keys and key maps
+00:05:52.680 --> 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:02.159 I have to repeat the entire keychord again.
+00:07:02.160 --> 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:30.119 Some might prefer that approach
+00:07:30.120 --> 00:07:33.079 to solving the same problem.
+00:07:33.080 --> 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:43.679 which you might or might not be interested in. NOTE EditorConfig
+00:07:43.680 --> 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:57.319 I believe I've linked to it down here somewhere.
+00:07:57.320 --> 00:08:02.239 Ah, there it is, EditorConfig.
+00:08:02.240 --> 00:08:06.519 This is a file format used to specify
+00:08:06.520 --> 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:25.639 Of course, this is restricted to the common subset
+00:08:25.640 --> 00:08:28.559 of what all editors should understand.
+00:08:28.560 --> 00:08:31.839 For example, indentation styles,
+00:08:31.840 --> 00:08:34.239 whether you prefer tabs or spaces,
+00:08:34.240 --> 00:08:38.759 tab width, file encoding, and so on.
+00:08:38.760 --> 00:08:42.559 So it's nothing too advanced, but it's something...
+00:08:42.560 --> 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:04.439 Though one should note that it's not enabled by default.
+00:09:04.440 --> 00:09:09.079 You still have to enable the global minor mode,
+00:09:09.080 --> 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:31.399 If it finds a .editorconfig file in the project directory,
+00:09:31.400 --> 00:09:35.839 then it will respect those rules
+00:09:35.840 --> 00:09:38.439 without having to do anything else. NOTE use-package integration with package-vc
+00:09:38.440 --> 00:09:45.039 Next up, use-package integration with package-vc.
+00:09:45.040 --> 00:09:48.039 For those not familiar with either of the two,
+00:09:48.040 --> 00:09:49.519 or at least one of the two,
+00:09:49.520 --> 00:09:52.159 use-package is a popular configuration macro.
+00:09:52.160 --> 00:09:54.399 What it does is it allows
+00:09:54.400 --> 00:09:56.959 users to declaratively specify packages
+00:09:56.960 --> 00:10:00.399 they would like to have installed and configured
+00:10:00.400 --> 00:10:01.759 in their configuration file,
+00:10:01.760 --> 00:10:05.879 so that, for example, if you copy your init.el
+00:10:05.880 --> 00:10:07.399 from one system to another,
+00:10:07.400 --> 00:10:09.959 it could bootstrap the entire configuration,
+00:10:09.960 --> 00:10:12.199 downloading all the packages you want
+00:10:12.200 --> 00:10:13.759 without having to manually do this
+00:10:13.760 --> 00:10:15.599 on every system you'd like to use.
+00:10:15.600 --> 00:10:19.119 This allows configurations
+00:10:19.120 --> 00:10:21.319 to be self-encapsulated and portable.
+00:10:21.320 --> 00:10:27.039 package-vc is an extension of package.el,
+00:10:27.040 --> 00:10:30.919 which allows installing packages from an alternative.
+00:10:30.920 --> 00:10:33.759 Instead of using the standard way to install packages,
+00:10:33.760 --> 00:10:37.039 which is just download tarball and unpack it,
+00:10:37.040 --> 00:10:39.479 byte compile, and so on,
+00:10:39.480 --> 00:10:44.119 it will fetch the files for a package
+00:10:44.120 --> 00:10:46.519 directly from the source code repository
+00:10:46.520 --> 00:10:48.679 and initialize it in such a way
+00:10:48.680 --> 00:10:50.319 that package.el can work with it.
+00:10:50.320 --> 00:10:54.239 So it's just a front-end for installing packages.
+00:10:54.240 --> 00:10:57.999 Even though these two were added to Emacs 29,
+00:10:58.000 --> 00:10:59.919 we didn't have the time to work on the
+00:10:59.920 --> 00:11:04.159 use-package integration of package-vc into use-package,
+00:11:04.160 --> 00:11:06.079 which has been changed now.
+00:11:06.080 --> 00:11:10.039 What we have with Emacs 30 is that
+00:11:10.040 --> 00:11:14.599 there is a :vc keyword for use-package
+00:11:14.600 --> 00:11:16.919 with which we can instruct use-package
+00:11:16.920 --> 00:11:20.599 to not download a package using tarball,
+00:11:20.600 --> 00:11:23.959 but instead to fetch the source code
+00:11:23.960 --> 00:11:25.279 from a source code repository.
+00:11:25.280 --> 00:11:27.079 This is useful if you, for example,
+00:11:27.080 --> 00:11:29.759 have packages which you yourself work on
+00:11:29.760 --> 00:11:31.439 and know that you always want to have
+00:11:31.440 --> 00:11:33.399 the development version of the package
+00:11:33.400 --> 00:11:37.359 where you can directly commit changes you've made
+00:11:37.360 --> 00:11:40.399 to the repository and push them upstream.
+00:11:40.400 --> 00:11:43.919 Or, if you know that you want to contribute to a package,
+00:11:43.920 --> 00:11:46.479 you can use package-vc to download the source code,
+00:11:46.480 --> 00:11:48.879 have all the version control information,
+00:11:48.880 --> 00:11:50.559 prepare a patch and send it upstream.
+00:11:50.560 --> 00:11:54.799 In these examples here,
+00:11:54.800 --> 00:12:00.679 the first example Lisp instructs package-vc
+00:12:00.680 --> 00:12:03.879 to download the source code from a URL.
+00:12:03.880 --> 00:12:06.919 So this is a git URL where it will download
+00:12:06.920 --> 00:12:08.919 the source code from, and in this case,
+00:12:08.920 --> 00:12:11.839 choose the newest checkout of the source code,
+00:12:11.840 --> 00:12:15.799 not the latest release. Down here, we have another example.
+00:12:15.800 --> 00:12:20.319 I prefer to consider the following example here.
+00:12:20.320 --> 00:12:22.399 If we just had written this,
+00:12:22.400 --> 00:12:24.719 then package-vc would use the metadata
+00:12:24.720 --> 00:12:26.959 which an ELPA server provides
+00:12:26.960 --> 00:12:31.719 to fetch the URL from the official repository of,
+00:12:31.720 --> 00:12:34.319 in this case, BBDB, without having to...
+00:12:34.320 --> 00:12:39.239 It would be more or less the same like this up here,
+00:12:39.240 --> 00:12:44.199 with the simple difference that package-vc integration
+00:12:44.200 --> 00:12:47.839 into use-package doesn't check out the latest commit,
+00:12:47.840 --> 00:12:49.319 but the latest release,
+00:12:49.320 --> 00:12:54.519 just to keep configurations more deterministic by default.
+00:12:54.520 --> 00:12:59.399 Of course, if you prefer to use latest commit,
+00:12:59.400 --> 00:13:01.799 you can use a package-vc install command
+00:13:01.800 --> 00:13:06.279 or just update the package manually yourself,
+00:13:06.280 --> 00:13:13.059 which you can use using package-vc-upgrade.
+00:13:13.060 --> 00:13:15.879 Next, I'd like to focus on a few features
+00:13:15.880 --> 00:13:18.919 which one might not necessarily realize directly,
+00:13:18.920 --> 00:13:22.859 but will hopefully improve your experience with Emacs. NOTE JSON
+00:13:22.860 --> 00:13:26.639 First up in this list is a new JSON parser.
+00:13:26.640 --> 00:13:29.759 Let's maybe show the source code for that one:
+00:13:29.760 --> 00:13:51.039 not json.el, json.c. The history of JSON parsing in Emacs
+00:13:51.040 --> 00:13:54.879 started with Emacs 23 with the addition of json.el.
+00:13:54.880 --> 00:13:58.239 This was the file which we had just opened a moment ago.
+00:13:58.240 --> 00:14:02.319 This is a JSON parser in Emacs Lisp.
+00:14:02.320 --> 00:14:04.759 It's fine, it does the job, but it can get slow
+00:14:04.760 --> 00:14:06.519 if we have a situation like where
+00:14:06.520 --> 00:14:11.239 Eglot uses a LSP server to communicate with
+00:14:11.240 --> 00:14:14.039 and the LSP server can get a bit chatty,
+00:14:14.040 --> 00:14:17.039 sending a lot of JSON data,
+00:14:17.040 --> 00:14:19.599 which all has to be parsed and garbage collected,
+00:14:19.600 --> 00:14:21.439 which can slow down Emacs a bit.
+00:14:21.440 --> 00:14:25.279 The situation was improved upon in Emacs 29
+00:14:25.280 --> 00:14:29.479 when JSON parsing was added to the core.
+00:14:29.480 --> 00:14:32.679 This was the json.c file, which we see on this side,
+00:14:32.680 --> 00:14:34.279 the old version of the json.c file,
+00:14:34.280 --> 00:14:38.279 which employed the Jansson library (it's the C library)
+00:14:38.280 --> 00:14:42.479 for parsing and accelerating JSON parsing in Emacs.
+00:14:42.480 --> 00:14:45.479 This was good enough,
+00:14:45.480 --> 00:14:47.719 or it certainly improved the situation
+00:14:47.720 --> 00:14:50.039 for a lot of LSP clients.
+00:14:50.040 --> 00:14:53.239 But in Emacs 30, the situation has been improved once more
+00:14:53.240 --> 00:15:01.174 with the addition of a JSON parser directly in Emacs.
+00:15:01.175 --> 00:15:03.874 So instead of using an external library,
+00:15:03.875 --> 00:15:08.879 there's a custom JSON parser written in C in the Emacs core,
+00:15:08.880 --> 00:15:12.240 which directly generates Elisp objects.
+00:15:12.241 --> 00:15:16.574 The advantage to this approach
+00:15:16.575 --> 00:15:18.007 compared to the Jansson approach
+00:15:18.008 --> 00:15:19.439 is that there's no intermediate format
+00:15:19.440 --> 00:15:20.879 which has to be allocated
+00:15:20.880 --> 00:15:23.159 and memory managed and freed again,
+00:15:23.160 --> 00:15:30.240 which of course incurs an additional performance overhead.
-Next to this, there's also a custom serializer +00:15:30.241 --> 00:15:35.639 +There is absolutely no dependency on Jansson anymore.
-for JSON contents translating a JSON object into a string. -
-... The consequence of this is that -
-there is absolutely no dependency on Jansson anymore. -
+00:15:35.640 --> 00:15:38.599 This in turn means that now all Emacs users
+00:15:38.600 --> 00:15:39.720 from Emacs 30 onwards
+00:15:39.760 --> 00:15:42.639 can take advantage of this new JSON parser
+00:15:42.640 --> 00:15:44.839 and don't have to worry about whether
+00:15:44.840 --> 00:15:47.759 or not they have Jansson, this JSON parsing library,
+00:15:47.760 --> 00:15:50.999 installed on their system or not when they want
+00:15:51.000 --> 00:15:56.799 to take advantage of this accelerated JSON parsing. NOTE Native compilation
+00:15:56.800 --> 00:16:00.279 Next up, another behind-the-scenes feature
+00:16:00.280 --> 00:16:03.959 is that if you build Emacs on your own from source,
+00:16:03.960 --> 00:16:07.759 you might know that if you wanted
+00:16:07.760 --> 00:16:09.479 to use native compilation,
+00:16:09.480 --> 00:16:13.119 so the translation of Elisp bytecodes
+00:16:13.120 --> 00:16:15.479 to whatever the native assembly
+00:16:15.480 --> 00:16:18.999 or native instruction set is on your system,
+00:16:19.000 --> 00:16:24.199 you have to specify with native compilation.
+00:16:24.200 --> 00:16:25.839 when invoking the configure script,
+00:16:25.840 --> 00:16:28.239 otherwise it would not have been enabled at all.
+00:16:28.240 --> 00:16:31.439 With Emacs 30, this step is not necessary anymore.
+00:16:31.440 --> 00:16:36.119 The configure script will automatically check
+00:16:36.120 --> 00:16:41.639 if you have the libgccjit library installed on your system,
+00:16:41.640 --> 00:16:42.759 and if that is so,
+00:16:42.760 --> 00:16:45.519 then native compilation will be enabled by default.
+00:16:45.520 --> 00:16:49.279 In other words, if you have an issue with native compilation
+00:16:49.280 --> 00:16:52.359 or prefer not to use it for whatever reason,
+00:16:52.360 --> 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.239 But native compilation was added in Emacs 28
+00:17:02.240 --> 00:17:04.319 and has proven to be a very stable
+00:17:04.320 --> 00:17:06.159 and useful feature for most people,
+00:17:06.160 --> 00:17:09.359 so there's probably no reason to do this
+00:17:09.360 --> 00:17:11.199 and you can just invoke the configure script
+00:17:11.200 --> 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:29.579 Maybe we can go back to the listing here. Here we have it. NOTE Tree-sitter
+00:17:29.580 --> 00:17:32.799 There are a few new major modes
+00:17:32.800 --> 00:17:34.239 based on the tree-sitter library.
+00:17:34.240 --> 00:17:37.519 tree-sitter is this parser library
+00:17:37.520 --> 00:17:42.699 which has been integrated into Emacs 29.
+00:17:42.700 --> 00:17:43.999 It allows the integration
+00:17:44.000 --> 00:17:48.359 of external, specialized, and quick parsers into Emacs,
+00:17:48.360 --> 00:17:52.039 which improve stuff like syntax highlighting, indentation,
+00:17:52.040 --> 00:17:55.159 structural navigation, imenu support,
+00:17:55.160 --> 00:18:00.839 by simply having a better understanding of, for example,
+00:18:00.840 --> 00:18:03.839 a HTML file, or a Lua file, a PHP file,
+00:18:03.840 --> 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.679 So, a few new major modes which you can try out here. NOTE Completion preview mode
+00:18:16.680 --> 00:18:19.959 Another interesting feature is the completion-preview-mode.
+00:18:19.960 --> 00:18:23.079 We can maybe try it out here in the scratch buffer.
+00:18:23.080 --> 00:18:28.199 If I enable completion-preview-mode...
+00:18:28.200 --> 00:18:31.999 This is a non-global minor mode,
+00:18:32.000 --> 00:18:38.479 which will display completion options inline using overlays.
+00:18:38.480 --> 00:18:43.079 For example, if I start typing a longer symbol like define,
+00:18:43.080 --> 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.799 but it didn't actually...
+00:18:51.800 --> 00:18:55.279 It's not actually modifying the buffer, it's not pressing,
+00:18:55.280 --> 00:18:56.999 these are just overlays,
+00:18:57.000 --> 00:18:59.479 so if I move around, it gets deleted.
+00:18:59.480 --> 00:19:01.519 It wouldn't get saved if I were to save the buffer.
+00:19:01.520 --> 00:19:04.879 The same also should work in a shell buffer.
+00:19:04.880 --> 00:19:08.439 If I enable completion preview mode here and start...
+00:19:08.440 --> 00:19:12.719 In this case, I'm using the bash completion package,
+00:19:12.720 --> 00:19:15.159 which provides additional completion information.
+00:19:15.160 --> 00:19:17.839 This is not only limited to programming systems,
+00:19:17.840 --> 00:19:22.879 but anywhere where you have completion at point in Emacs.
+00:19:22.880 --> 00:19:26.599 I can start typing here, ignore, and put ignore-backups,
+00:19:26.600 --> 00:19:29.879 and it hints to the options which I have
+00:19:29.880 --> 00:19:33.239 and allows me to complete them quickly. NOTE package-isolate
+00:19:33.240 --> 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.719 or it will prompt me for packages
+00:19:42.720 --> 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.239 with only these packages installed.
+00:19:53.240 --> 00:20:00.359 So for example, if I said I want slime and I want diff-hl,
+00:20:00.360 --> 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.759 It uses the same executable, of course,
+00:20:06.760 --> 00:20:08.999 but will not load your configuration file
+00:20:09.000 --> 00:20:13.079 or any other further customizations on your system.
+00:20:13.080 --> 00:20:15.159 All it does, it will ensure
+00:20:15.160 --> 00:20:17.879 that these packages, which are listed here,
+00:20:17.880 --> 00:20:24.359 so in our case SLIME and dependencies of SLIME and diff-hl,
+00:20:24.360 --> 00:20:25.119 in the system
+00:20:25.120 --> 00:20:28.999 so that I could, for example, as you can see here,
+00:20:29.000 --> 00:20:32.019 diff-hl-mode works.
+00:20:32.020 --> 00:20:35.319 Okay, this is not a version-controlled file.
+00:20:35.320 --> 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.239 is it displays these version control changes
+00:20:48.240 --> 00:20:49.999 in the fringe of a buffer.
+00:20:50.000 --> 00:20:54.039 And even though this is a uncustomized version of Emacs,
+00:20:54.040 --> 00:20:56.279 or an uncustomized instance of Emacs,
+00:20:56.280 --> 00:20:58.919 it was easy for me to load this one package,
+00:20:58.920 --> 00:21:01.959 or these two packages and all the dependencies necessary.
+00:21:01.960 --> 00:21:04.759 As you can imagine, the main purpose for this
+00:21:04.760 --> 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:15.959 and everything's thrown away. NOTE Reindenting
+00:21:15.960 --> 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:29.119 The M-q key is traditionally bound to fill-paragraph.
+00:21:29.120 --> 00:21:32.119 What this means is that...
+00:21:32.120 --> 00:21:34.919 Let's, for example, copy this text from here
+00:21:34.920 --> 00:21:40.279 and squash it all into one line. If I press M-q here,
+00:21:40.280 --> 00:21:43.679 then the lines will be broken
+00:21:43.680 --> 00:21:49.599 according to the fill column indicator up here.
+00:21:49.600 --> 00:21:52.199 This is the traditional usage of M-q,
+00:21:52.200 --> 00:21:54.159 and it still works in text-mode buffers,
+00:21:54.160 --> 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.639 to prog-fill-reindent-defun. To summarize the point,
+00:22:09.640 --> 00:22:13.359 if you are editing a string or a comment,
+00:22:13.360 --> 00:22:15.939 then the comment will be filled.
+00:22:15.940 --> 00:22:19.039 But if you are outside of a comment or outside of a string,
+00:22:19.040 --> 00:22:22.919 then the defun or the top-level construct
+00:22:22.920 --> 00:22:25.559 in the programming language will be re-indented.
+00:22:25.560 --> 00:22:33.879 Let's try that out with maybe some file I have open here.
+00:22:33.880 --> 00:22:37.719 If I'm in this... Let's choose some function,
+00:22:37.720 --> 00:22:41.279 let's take this for example.
+00:22:41.280 --> 00:22:42.879 If we followed all of this again,
+00:22:42.880 --> 00:22:46.479 and I press M-q in on this paragraph,
+00:22:46.480 --> 00:22:49.399 then the paragraph gets re-indented.
+00:22:49.400 --> 00:22:55.759 But if I'm down here and I choose to break the indentation
+00:22:55.760 --> 00:22:58.239 and then press M-q,
+00:22:58.240 --> 00:23:02.279 then as you see, it practically selected the defun
+00:23:02.280 --> 00:23:03.559 and re-indented everything
+00:23:03.560 --> 00:23:06.699 without having me to move the point around in the buffer.
+00:23:06.700 --> 00:23:08.559 So I think that's a really nice feature,
+00:23:08.560 --> 00:23:12.919 which a lot of people can appreciate.
+00:23:12.920 --> 00:23:18.279 It's one of those niceties which comes from time to time. NOTE Wrapping up
+00:23:18.280 --> 00:23:20.599 Right, so that was my overview
+00:23:20.600 --> 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:26.159 something from this presentation
+00:23:26.160 --> 00:23:28.959 and have something to look forward
+00:23:28.960 --> 00:23:31.039 to try out after upgrading.
+00:23:31.040 --> 00:23:33.759 As mentioned initially, as of recording,
+00:23:33.760 --> 00:23:36.519 this release has not been completed yet.
+00:23:36.520 --> 00:23:38.799 If this is still not the case
+00:23:38.800 --> 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.159 If you have any issues, which is always the case,
+00:23:48.160 --> 00:23:51.959 please report them to using report-emacs-bug.
+00:23:51.960 --> 00:23:55.079 That will pop up a mail buffer,
+00:23:55.080 --> 00:23:59.519 and then you can describe your issue and send them out.
+00:23:59.520 --> 00:24:01.759 All bug reports are valuable,
+00:24:01.760 --> 00:24:04.359 even if they are false positives or duplicates--
+00:24:04.360 --> 00:24:05.159 it doesn't matter--
+00:24:05.160 --> 00:24:08.439 because when you take the time to submit a bug report,
+00:24:08.440 --> 00:24:12.159 which describes something that's specific to your setup,
+00:24:12.160 --> 00:24:16.639 which the developers might not have noticed or known about,
+00:24:16.640 --> 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.119 Especially with upgrades,
+00:24:23.120 --> 00:24:26.559 it would be nice to figure out small problems
+00:24:26.560 --> 00:24:30.759 which make upgrading difficult for some people.
+00:24:30.760 --> 00:24:34.559 The ideal is, of course, to have no issues
+00:24:34.560 --> 00:24:36.159 when upgrading from one version to another.
+00:24:36.160 --> 00:24:39.519 Having said that, I thank you for your attention,
+00:24:39.520 --> 00:24:43.680 and I'm saying goodbye. -- cgit v1.2.3