WEBVTT captioned by anush and sachac, checked by anush and bhavin NOTE Introduction 00:00.000 --> 00:06.066 Hello, and welcome to Emacs 30 Highlights at EmacsConf 2024. 00:06.100 --> 00:08.833 Before I begin, I'd like to thank the organizers 00:08.866 --> 00:11.800 and everyone involved for putting this all together. 00:11.800 --> 00:13.733 While this talk is being pre-recorded, 00:13.766 --> 00:15.233 my experience from the last few years 00:15.266 --> 00:19.100 assures me that it will be a great experience for everyone. 00:19.133 --> 00:21.300 My name is Philip Kaludercic. 00:21.333 --> 00:24.466 I am a core contributor and ELPA co-maintainer. 00:24.500 --> 00:26.066 I was honored when Sacha asked me 00:26.100 --> 00:28.333 to take over the slot for this year. 00:28.366 --> 00:29.866 In the past few iterations, 00:29.900 --> 00:32.133 John Wiegley has filled a similar presentation 00:32.166 --> 00:35.666 focusing on more general Emacs development updates. 00:35.700 --> 00:00:38.501 This year, I will specifically focus on 00:00:38.502 --> 00:00:41.900 highlight features from the upcoming Emacs 30 release, 00:41.933 --> 00:44.200 which might or might not have been released 00:44.200 --> 00:00:48.059 by the time you are seeing this. 00:00:48.060 --> 00:51.266 As you can imagine, everything new about Emacs 00:51.300 --> 00:55.133 can always be found in the Emacs NEWS file. 00:55.166 --> 00:57.100 Or, alternatively, 00:57.133 --> 01:01.800 if one doesn't want to read through the 3,000 lines here, 01:01.800 --> 01:05.233 one can also take a look at the Emacs FAQ 01:05.266 --> 01:08.000 and then go to the what's new about 01:08.000 --> 01:12.300 or what's different about Emacs 30 node. 01:12.333 --> 01:14.700 Next to these two official options, 01:14.733 --> 01:18.200 I also have a page on Emacs Wiki 01:18.200 --> 01:21.300 called EmacsThirtyHighlights, 01:21.333 --> 01:24.266 highlighting some of the interesting features 01:24.300 --> 01:28.433 with some context and suggestions on how to try them out. 01:28.466 --> 01:30.033 This is more of a collaborative effort. 01:30.066 --> 01:32.733 So if you see this and think something is missing, 01:32.766 --> 01:34.500 feel free to add it. 01:34.533 --> 01:36.833 So without further ado, 01:36.866 --> 01:41.800 let's begin taking a look at new features in Emacs 30. NOTE Android 01:41.800 --> 01:44.700 The biggest one, and the one I want to mention first, 01:44.733 --> 01:49.033 is Android support, native Android support. 01:49.066 --> 01:51.833 As you can see here, Emacs has been ported 01:51.866 --> 01:53.666 to the Android operating system. 01:53.700 --> 01:56.500 What this means is that from Emacs 30 onwards, 01:56.533 --> 02:01.066 you can build Android to target Android devices natively 02:01.100 --> 02:06.733 and using a graphical interface. 02:06.766 --> 02:08.433 While it has been possible to run Emacs 02:08.466 --> 02:11.133 inside of terminal emulators on Android for a while, 02:11.166 --> 02:13.900 this actually means that you can use Emacs 02:13.933 --> 02:17.533 on an Android device, a phone or a tablet, 02:17.566 --> 02:20.933 and have all the usual advantages from GUI Emacs, 02:20.966 --> 02:23.466 such as the ability to bind all commands 02:23.500 --> 02:25.466 without having to worry about-- 02:25.500 --> 02:27.266 all keys without having to worry 02:27.300 --> 02:29.033 about terminal compatibility issues, 02:29.066 --> 02:32.733 displaying images and multiple fonts 02:32.766 --> 02:35.333 on the same display of different sizes. 02:35.366 --> 02:37.300 I should have a recording 02:37.333 --> 02:42.200 of that somewhere here--here we are-- 02:42.200 --> 02:44.100 which I made earlier on my phone, 02:44.133 --> 02:47.266 because I'm recording this on a laptop-- 02:47.300 --> 02:50.466 where we can see how touch interaction works 02:50.500 --> 02:53.333 on an Android phone. I can switch between buffers. 02:53.366 --> 02:56.100 Here I've connected an external keyboard, 02:56.133 --> 02:57.800 opening the Emacs website. 02:57.800 --> 00:03:02.559 We have images that we can interact with. 00:03:02.560 --> 00:03:04.319 We could resize them if we wanted to 00:03:04.320 --> 03:07.400 with the image resizing commands. 03:07.400 --> 03:10.300 Pinch-to-zoom works, so it 03:10.333 --> 03:12.733 does realize what touchscreen interactions are. 03:12.766 --> 03:15.233 With an external mouse, and for example, 03:15.266 --> 03:17.800 enabling context menu mode, 03:17.800 --> 03:23.066 I can even pop up little interaction windows, 03:23.100 --> 00:03:28.139 which one you would usually also know from GUI Emacs. 00:03:28.140 --> 03:33.200 TUI Emacs actually also supports them since a while now. 03:33.200 --> 03:34.600 And in this case, I'm demonstrating 03:34.600 --> 03:36.000 how even the touchscreen events 03:36.000 --> 03:39.133 can be inspected using the usual help system, 03:39.166 --> 03:43.333 and how context-mode notices 03:43.366 --> 03:45.200 where we are and allows me to, for example, 03:45.200 --> 03:47.800 evaluate this specific region, 03:47.800 --> 03:49.300 which I've highlighted down there, 03:49.333 --> 03:58.300 binding a command to touch-screen-scroll. Yeah. 03:58.333 --> 04:00.533 One should note that these additions, 04:00.566 --> 04:02.400 for example touchscreen interaction, 04:02.400 --> 04:03.833 are not specific to Android, 04:03.866 --> 04:07.066 but they also are supported in other operating systems, 04:07.100 --> 04:12.200 such as Wayland and Xorg, which are not operating systems, 04:12.200 --> 04:15.300 and Windows, insofar as they have touchscreen, 04:15.333 --> 00:04:18.419 and devices have touchscreen support. 00:04:18.420 --> 04:21.300 One should mention, or I want to mention, 04:21.333 --> 04:24.666 that the main developer behind this feature, Po Lu, 04:24.700 --> 04:27.500 should be complimented for the additional effort he put 04:27.533 --> 00:04:31.019 into making sure that Emacs for Android 00:04:31.020 --> 04:34.133 can be built using only a free software toolchain, 04:34.166 --> 00:04:36.359 which is certainly not something one has come to expect 00:04:36.360 --> 04:40.700 from working on Android applications, 04:40.733 --> 04:43.833 as usually you have to agree to some terms and conditions 04:43.866 --> 00:04:46.519 for Google-specific software. 00:04:46.520 --> 04:49.633 Final note is that if you try and look for this online, 04:49.666 --> 04:52.133 there are APKs you can find, 04:52.166 --> 04:54.666 but some of them might be outdated. 04:54.700 --> 04:59.333 To the best of my knowledge, Po Lu has... 04:59.366 --> 05:03.400 Emacs 30 Android Sourceforge... 05:03.400 --> 05:06.500 He has set up some system where here in Sourceforge, 05:06.533 --> 05:12.433 there are regular and updated 05:12.466 --> 05:14.500 APK files which you can download 05:14.533 --> 05:16.933 to avoid having to build it yourself, 05:16.966 --> 05:18.866 testing out the newest version 05:18.900 --> 05:24.133 in case there are some bugs which you'd like to report. 05:24.166 --> 05:33.100 Which-key is a package which has now been moved 05:33.133 --> 05:35.266 from ELPA to the core. 05:35.300 --> 00:05:39.179 If you haven't heard of which-key before, the idea is, 00:05:39.180 --> 05:41.633 or the general pitch is that which-key 05:41.666 --> 05:45.233 is a additional documentation interface for Emacs 05:45.266 --> 05:49.700 for displaying various keys which you could input, 05:49.733 --> 00:05:53.439 or various keys and key maps 00:05:53.440 --> 05:54.833 that have been partially inputted. 05:54.866 --> 05:57.633 A better way to demonstrate this 05:57.666 --> 05:59.300 or to explain this is just to show it. 05:59.333 --> 06:03.466 If we enable the which-key mode--it's a global minor mode-- 06:03.500 --> 06:06.333 then I can press, for example, C-x, 06:06.366 --> 06:08.700 which is a prefix for the C-x keymap. 06:08.733 --> 06:12.433 Then down here in the buffer, in this window down here, 06:12.466 --> 06:15.333 we see various commands which we could invoke 06:15.366 --> 06:17.900 and the keys to invoke them with. 06:17.933 --> 06:23.000 For example, if I wanted to say C-x i for insert-file, 06:23.000 --> 06:27.233 then I just have to press i to highlight it once again. 06:27.266 --> 06:32.600 It should be down here. Pressing i without having to repeat 06:32.600 --> 06:34.733 the entire key code again, 06:34.766 --> 06:37.200 the partial key code again, just works. 06:37.200 --> 06:41.533 This is different from the feature which Emacs has already, 06:41.566 --> 06:45.400 which is if you have input the partial keychord, 06:45.400 --> 06:47.033 you can press C-h 06:47.066 --> 06:51.000 and then a help buffer pops up with a listing 06:51.000 --> 06:54.066 of all keybindings that start with C-x. 06:54.100 --> 06:56.633 The information is the same, the presentation is different, 06:56.666 --> 06:59.066 because now if I wanted to do C-x i, 06:59.100 --> 00:07:03.339 I have to repeat the entire keychord again. 00:07:03.340 --> 07:09.466 So it's a matter of personal preference, which you prefer. 07:09.500 --> 00:07:10.959 This is more of a traditional static approach 00:07:10.960 --> 07:19.633 because I get a help buffer which I can search 07:19.666 --> 07:20.900 using usual key commands, 07:20.933 --> 07:28.133 while which-key is more of a transient and modern. 07:28.166 --> 07:31.400 Some might prefer that approach 07:31.400 --> 00:07:35.719 to solving the same problem. 00:07:35.720 --> 07:39.100 Also, don't forget to check out the customization group 07:39.133 --> 07:41.933 for which-key which has a number of options 07:41.966 --> 00:07:45.719 which you might or might not be interested in. NOTE EditorConfig 00:07:45.720 --> 07:50.866 Next up, Emacs 30 has built-in EditorConfig support. 07:50.900 --> 07:53.633 If you have not heard of EditorConfig before, 07:53.666 --> 00:07:56.639 I believe I've linked to it down here somewhere. 00:07:56.640 --> 00:08:00.119 Ah, there it is, EditorConfig. 00:08:00.120 --> 00:08:09.419 This is a file format used to specify 00:08:09.420 --> 08:12.133 common formatting rules in an editor-agnostic way. 08:12.166 --> 08:16.266 You might compare it to .dir-locals.el files, 08:16.300 --> 08:19.333 which is a sort of an s-expression 08:19.366 --> 08:22.233 for setting file-local variables in Emacs. 08:22.266 --> 08:27.266 Of course, this is restricted to the common subset 08:27.300 --> 08:29.400 of what all editors should understand. 08:29.400 --> 08:31.833 For example, indentation styles, 08:31.866 --> 00:08:35.119 whether you prefer tabs or spaces, 00:08:35.120 --> 08:38.733 tab width, file encoding, and so on. 08:38.766 --> 00:08:43.919 So it's nothing too advanced, but it's something... 00:08:43.920 --> 08:48.500 It is a file format which one sees popping up more 08:48.533 --> 08:50.433 and more often in lots of projects 08:50.466 --> 08:53.600 which want to enforce a consistent indentation style 08:53.600 --> 08:56.633 or formatting rules for all editors in a project. 08:56.666 --> 09:00.200 Having this built in is certainly useful in Emacs. 09:00.200 --> 09:03.466 Though one should note that it's not enabled by default. 09:03.500 --> 00:09:10.939 You still have to enable the global minor mode, 00:09:10.940 --> 09:14.200 which is simply turning on this one option. 09:14.200 --> 09:15.500 Shouldn't be more than that, 09:15.533 --> 09:18.633 and then Emacs will respect the rules. 09:18.666 --> 00:09:23.640 If it finds a .editorconfig file in the project directory, 00:09:23.641 --> 00:09:25.320 then it will respect those rules 00:09:25.321 --> 00:09:27.320 without having to do anything else. NOTE use-package integration with package-vc 00:09:27.310 --> 00:09:33.567 Next up, use-package integration with package-vc. 00:09:33.568 --> 00:09:36.533 For those not familiar with either of the two, 00:09:36.534 --> 00:09:37.533 or at least one of the two, 00:09:37.534 --> 00:09:40.699 use-package is a popular configuration macro. 00:09:40.700 --> 00:09:42.833 What it does is it allows 00:09:42.866 --> 00:09:46.233 users to declaratively specify packages 00:09:46.266 --> 00:09:48.900 they would like to have installed and configured 00:09:48.900 --> 00:09:51.659 in their configuration file, 00:09:51.660 --> 00:09:54.400 so that, for example, if you copy your init.el 00:09:54.433 --> 00:09:55.900 from one system to another, 00:09:55.900 --> 00:09:58.500 it could bootstrap the entire configuration, 00:09:58.500 --> 00:10:00.733 downloading all the packages you want 00:10:00.766 --> 00:10:02.366 without having to manually do this 00:10:02.400 --> 00:10:05.139 on every system you'd like to use. 00:10:05.140 --> 00:10:07.600 This allows configurations 00:10:07.633 --> 00:10:10.859 to be self-encapsulated and portable. 00:10:10.860 --> 00:10:15.059 package-vc is an extension of package.el, 00:10:15.060 --> 00:10:19.400 which allows installing packages from an alternative. 00:10:19.433 --> 00:10:22.366 Instead of using the standard way to install packages, 00:10:22.400 --> 00:10:26.499 which is just download tarball and unpack it, 00:10:26.500 --> 00:10:27.933 byte compile, and so on, 00:10:27.966 --> 00:10:32.399 it will fetch the files for a package 00:10:32.400 --> 00:10:34.966 directly from the source code repository 00:10:35.000 --> 00:10:37.233 and initialize it in such a way 00:10:37.266 --> 00:10:38.800 that package.el can work with it. 00:10:38.833 --> 00:10:44.239 So it's just a front-end for installing packages. 00:10:44.240 --> 00:10:46.500 Even though these two were added to Emacs 29, 00:10:46.500 --> 00:10:48.366 we didn't have the time to work on the 00:10:48.400 --> 00:10:52.500 use-package integration of package-vc into use-package, 00:10:52.500 --> 00:10:54.600 which has been changed now. 00:10:54.633 --> 00:11:00.139 What we have with Emacs 30 is that 00:11:00.140 --> 00:11:02.833 there is a :vc keyword for use-package 00:11:02.866 --> 00:11:05.200 with which we can instruct use-package 00:11:05.233 --> 00:11:10.239 to not download a package using tarball, 00:11:10.240 --> 00:11:12.433 but instead to fetch the source code 00:11:12.466 --> 00:11:13.766 from a source code repository. 00:11:13.800 --> 00:11:15.566 This is useful if you, for example, 00:11:15.600 --> 00:11:18.200 have packages which you yourself work on 00:11:18.233 --> 00:11:19.933 and know that you always want to have 00:11:19.966 --> 00:11:21.900 the development version of the package 00:11:21.900 --> 00:11:26.819 where you can directly commit changes you've made 00:11:26.820 --> 00:11:29.733 to the repository and push them upstream. 00:11:29.766 --> 00:11:32.100 Or, if you know that you want to contribute to a package, 00:11:32.100 --> 00:11:34.966 you can use package-vc to download the source code, 00:11:35.000 --> 00:11:37.366 have all the version control information, 00:11:37.400 --> 00:11:41.739 prepare a patch and send it upstream. 00:11:41.740 --> 00:11:43.800 In these examples here, 00:11:43.833 --> 00:11:49.166 the first example Lisp instructs package-vc 00:11:49.200 --> 00:11:52.366 to download the source code from a URL. 00:11:52.400 --> 00:11:55.400 So this is a git URL where it will download 00:11:55.433 --> 00:11:57.400 the source code from, and in this case, 00:11:57.433 --> 00:12:00.000 choose the newest checkout of the source code, 00:12:00.033 --> 00:12:04.939 not the latest release. Down here, we have another example. 00:12:04.940 --> 00:12:08.766 I prefer to consider the following example here. 00:12:08.800 --> 00:12:10.733 If we just had written this, 00:12:10.766 --> 00:12:13.200 then package-vc would use the metadata 00:12:13.233 --> 00:12:15.000 which an ELPA server provides 00:12:15.033 --> 00:12:20.166 to fetch the URL from the official repository of, 00:12:20.200 --> 00:12:22.833 in this case, BBDB, without having to... 00:12:22.866 --> 00:12:27.733 It would be more or less the same like this up here, 00:12:27.766 --> 00:12:32.700 with the simple difference that package-vc integration 00:12:32.700 --> 00:12:36.300 into use-package doesn't check out the latest commit, 00:12:36.300 --> 00:12:37.766 but the latest release, 00:12:37.800 --> 00:12:44.979 just to keep configurations more deterministic by default. 00:12:44.980 --> 00:12:47.566 Of course, if you prefer to use latest commit, 00:12:47.600 --> 00:12:52.179 you can use a package-vc install command 00:12:52.180 --> 00:12:54.933 or just update the package manually yourself, 00:12:54.966 --> 00:13:01.779 which you can use using package-vc-upgrade. 00:13:01.780 --> 00:13:04.366 Next, I'd like to focus on a few features 00:13:04.400 --> 00:13:07.000 which one might not necessarily realize directly, 00:13:07.033 --> 00:13:11.559 but will hopefully improve your experience with Emacs. NOTE JSON 00:13:11.560 --> 00:13:15.133 First up in this list is a new JSON parser. 00:13:15.166 --> 00:13:21.959 Let's maybe show the source code for that one: 00:13:21.960 --> 00:13:39.533 not json.el, json.c. The history of JSON parsing in Emacs 00:13:39.566 --> 00:13:43.366 started with Emacs 23 with the addition of json.el. 00:13:43.400 --> 00:13:46.766 This was the file which we had just opened a moment ago. 00:13:46.800 --> 00:13:50.366 This is a JSON parser in Emacs Lisp. 00:13:50.400 --> 00:13:53.233 It's fine, it does the job, but it can get slow 00:13:53.266 --> 00:13:55.000 if we have a situation like where 00:13:55.033 --> 00:14:00.319 Eglot uses a LSP server to communicate with 00:14:00.320 --> 00:14:02.999 and the LSP server can get a bit chatty, 00:14:03.000 --> 00:14:05.133 sending a lot of JSON data, 00:14:05.166 --> 00:14:07.966 which all has to be parsed and garbage collected, 00:14:08.000 --> 00:14:09.933 which can slow down Emacs a bit. 00:14:09.966 --> 00:14:13.733 The situation was improved upon in Emacs 29 00:14:13.766 --> 00:14:18.000 when JSON parsing was added to the core. 00:14:18.033 --> 00:14:21.000 This was the json.c file, which we see on this side, 00:14:21.033 --> 00:14:22.733 the old version of the json.c file, 00:14:22.766 --> 00:14:26.700 which employed the Jansson library (it's the C library) 00:14:26.700 --> 00:14:31.899 for parsing and accelerating JSON parsing in Emacs. 00:14:31.900 --> 00:14:33.966 This was good enough, 00:14:34.000 --> 00:14:36.200 or it certainly improved the situation 00:14:36.233 --> 00:14:38.300 for a lot of LSP clients. 00:14:38.300 --> 00:14:44.766 But in Emacs 30, the situation has been improved once more 00:14:44.800 --> 00:14:49.800 with the addition of a JSON parser directly in Emacs. 00:14:49.833 --> 00:14:53.566 So instead of using an external library, 00:14:53.600 --> 00:14:57.400 there's a custom JSON parser written in C in the Emacs core, 00:14:57.433 --> 00:15:01.539 which directly generates Elisp objects. 00:15:01.540 --> 00:15:05.033 The advantage to this approach 00:15:05.066 --> 00:15:06.433 compared to the Jansson approach 00:15:06.466 --> 00:15:07.933 is that there's no intermediate format 00:15:07.966 --> 00:15:09.200 which has to be allocated 00:15:09.233 --> 00:15:11.500 and memory managed and freed again, 00:15:11.500 --> 00:15:19.539 which of course incurs an additional performance overhead. 00:15:19.540 --> 00:15:22.433 Next to this, there's also a custom serializer 00:15:22.466 --> 00:15:29.239 for JSON contents translating a JSON object into a string. 00:15:29.240 --> 00:15:30.640 ... The consequence of this is that 00:15:30.641 --> 00:15:35.519 there is absolutely no dependency on Jansson anymore. 00:15:35.520 --> 00:15:38.533 This in turn means that now all Emacs users 00:15:38.566 --> 00:15:39.800 from Emacs 30 onwards 00:15:39.833 --> 00:15:42.733 can take advantage of this new JSON parser 00:15:42.766 --> 00:15:44.933 and don't have to worry about whether 00:15:44.966 --> 00:15:47.633 or not they have Jansson, this JSON parsing library, 00:15:47.666 --> 00:15:50.433 installed on their system or not when they want 00:15:50.466 --> 00:15:56.679 to take advantage of this accelerated JSON parsing. NOTE Native compilation 00:15:56.680 --> 00:16:00.366 Next up, another behind-the-scenes feature 00:16:00.400 --> 00:16:06.406 is that if you build Emacs on your own from source, 00:16:06.407 --> 00:16:07.766 you might know that if you wanted 00:16:07.800 --> 00:16:09.533 to use native compilation, 00:16:09.566 --> 00:16:12.379 so the translation of Elisp bytecodes 00:16:12.380 --> 00:16:15.533 to whatever the native assembly 00:16:15.566 --> 00:16:19.133 or native instruction set is on your system, 00:16:19.166 --> 00:16:24.339 you have to specify with native compilation. 00:16:24.340 --> 00:16:25.933 when invoking the configure script, 00:16:25.966 --> 00:16:28.366 otherwise it would not have been enabled at all. 00:16:28.400 --> 00:16:32.479 With Emacs 30, this step is not necessary anymore. 00:16:32.480 --> 00:16:36.233 The configure script will automatically check 00:16:36.266 --> 00:16:41.700 if you have the libgccjit library installed on your system, 00:16:41.700 --> 00:16:42.766 and if that is so, 00:16:42.800 --> 00:16:45.566 then native compilation will be enabled by default. 00:16:45.600 --> 00:16:49.400 In other words, if you have an issue with native compilation 00:16:49.433 --> 00:16:52.500 or prefer not to use it for whatever reason, 00:16:52.500 --> 00:16:55.533 you now have to type --without-native-compilation 00:16:55.566 --> 00:16:58.433 when compiling Emacs to prevent this from happening. 00:16:58.466 --> 00:17:02.433 But native compilation was added in Emacs 28 00:17:02.466 --> 00:17:04.333 and has proven to be a very stable 00:17:04.366 --> 00:17:06.233 and useful feature for most people, 00:17:06.266 --> 00:17:09.400 so there's probably no reason to do this 00:17:09.433 --> 00:17:11.133 and you can just invoke the configure script 00:17:11.166 --> 00:17:16.300 with one argument less. Right, and I'd like to finish up 00:17:16.300 --> 00:17:19.500 with a few smaller features, a few smaller highlights. 00:17:19.500 --> 00:17:29.639 Maybe we can go back to the listing here. Here we have it. NOTE Tree-sitter 00:17:29.640 --> 00:17:32.833 There are a few new major modes 00:17:32.866 --> 00:17:34.333 based on the tree-sitter library. 00:17:34.366 --> 00:17:37.939 tree-sitter is this parser library 00:17:37.940 --> 00:17:39.933 which has been integrated into Emacs 29. 00:17:39.966 --> 00:17:44.100 It allows the integration 00:17:44.100 --> 00:17:48.400 of external, specialized, and quick parsers into Emacs, 00:17:48.433 --> 00:17:52.133 which improve stuff like syntax highlighting, indentation, 00:17:52.166 --> 00:17:55.233 structural navigation, imenu support, 00:17:55.266 --> 00:18:01.033 by simply having a better understanding of, for example, 00:18:01.066 --> 00:18:03.900 a HTML file, or a Lua file, a PHP file, 00:18:03.900 --> 00:18:06.233 than what people usually implement 00:18:06.266 --> 00:18:10.366 using regular expressions in traditional major modes. 00:18:10.400 --> 00:18:16.779 So, a few new major modes which you can try out here. NOTE Completion preview mode 00:18:16.780 --> 00:18:20.033 Another interesting feature is the completion-preview-mode. 00:18:20.066 --> 00:18:22.966 We can maybe try it out here in the scratch buffer. 00:18:23.000 --> 00:18:28.300 If I enable completion-preview-mode... 00:18:28.300 --> 00:18:32.033 This is a non-global minor mode, 00:18:32.066 --> 00:18:38.600 which will display completion options inline using overlays. 00:18:38.633 --> 00:18:43.133 For example, if I start typing a longer symbol like define, 00:18:43.166 --> 00:18:48.200 now we have a derived mode. It suggests me to... 00:18:48.233 --> 00:18:51.133 I can just press TAB and then it completes the option here, 00:18:51.166 --> 00:18:51.933 but it didn't actually... 00:18:51.966 --> 00:18:55.333 It's not actually modifying the buffer, it's not pressing, 00:18:55.366 --> 00:18:57.100 these are just overlays, 00:18:57.100 --> 00:18:59.533 so if I move around, it gets deleted. 00:18:59.566 --> 00:19:02.619 It wouldn't get saved if I were to save the buffer. 00:19:02.620 --> 00:19:04.966 The same also should work in a shell buffer. 00:19:05.000 --> 00:19:08.366 If I enable completion preview mode here and start... 00:19:08.400 --> 00:19:12.800 In this case, I'm using the bash completion package, 00:19:12.833 --> 00:19:15.000 which provides additional completion information. 00:19:15.033 --> 00:19:17.933 This is not only limited to programming systems, 00:19:17.966 --> 00:19:22.900 but anywhere where you have completion at point in Emacs. 00:19:22.900 --> 00:19:26.159 I can start typing here, ignore, and put ignore-backups, 00:19:26.160 --> 00:19:30.000 and it hints to the options which I have 00:19:30.033 --> 00:19:34.200 and allows me to complete them quickly. NOTE package-isolate 00:19:34.233 --> 00:19:37.966 Another small feature is the package-isolate command. 00:19:38.000 --> 00:19:40.000 What this does is it will start 00:19:40.033 --> 00:19:42.800 or it will prompt me for packages 00:19:42.833 --> 00:19:44.333 I have installed in my system 00:19:44.366 --> 00:19:46.500 and will start an isolated 00:19:46.500 --> 00:19:51.133 or like "emacs -Q"-ish instance of emacs 00:19:51.166 --> 00:19:53.333 with only these packages installed. 00:19:53.366 --> 00:20:00.439 So for example, if I said I want slime and I want diff-hl, 00:20:00.440 --> 00:20:02.700 then this is a new Emacs window. 00:20:02.700 --> 00:20:04.533 It's unrelated to the one around. 00:20:04.566 --> 00:20:06.500 It uses the same executable, of course, 00:20:06.500 --> 00:20:09.939 but will not load your configuration file 00:20:09.940 --> 00:20:13.679 or any other further customizations on your system. 00:20:13.680 --> 00:20:15.533 All it does, it will ensure 00:20:15.566 --> 00:20:17.933 that these packages, which are listed here, 00:20:17.966 --> 00:20:24.599 so in our case SLIME and dependencies of SLIME and diff-hl, 00:20:24.600 --> 00:20:25.300 in the system 00:20:25.300 --> 00:20:29.100 so that I could, for example, as you can see here, 00:20:29.100 --> 00:20:32.139 diff-hl-mode works. 00:20:32.140 --> 00:20:34.766 Okay, this is not a version-controlled file. 00:20:34.800 --> 00:20:41.200 Maybe if we take a look at, have I enabled diff-hl-mode? 00:20:41.233 --> 00:20:44.600 It's enabled in this case. What diff-hl-mode does 00:20:44.633 --> 00:20:48.300 is it displays these version control changes 00:20:48.300 --> 00:20:49.566 in the fringe of a buffer. 00:20:49.600 --> 00:20:54.133 And even though this is a uncustomized version of Emacs, 00:20:54.166 --> 00:20:56.333 or an uncustomized instance of Emacs, 00:20:56.366 --> 00:20:59.000 it was easy for me to load this one package, 00:20:59.033 --> 00:21:02.033 or these two packages and all the dependencies necessary. 00:21:02.066 --> 00:21:05.300 As you can imagine, the main purpose for this 00:21:05.300 --> 00:21:07.733 is to make debugging issues easier. 00:21:07.766 --> 00:21:10.566 If you want to report about an issue 00:21:10.600 --> 00:21:14.900 you have with a package. And if I close this, it's closed 00:21:14.900 --> 00:21:16.919 and everything's thrown away. NOTE Reindenting 00:21:16.920 --> 00:21:19.000 Last up, a nice feature I think 00:21:19.033 --> 00:21:20.933 a lot of people will appreciate is, 00:21:20.966 --> 00:21:24.300 if you are familiar with... Let's open a text buffer. 00:21:24.300 --> 00:21:30.279 The M-q key is traditionally bound to fill-paragraph. 00:21:30.280 --> 00:21:32.200 What this means is that... 00:21:32.233 --> 00:21:35.000 Let's, for example, copy this text from here 00:21:35.033 --> 00:21:40.366 and squash it all into one line. If I press M-q here, 00:21:40.400 --> 00:21:42.719 then the lines will be broken 00:21:42.720 --> 00:21:49.879 according to the fill column indicator up here. 00:21:49.880 --> 00:21:52.600 This is the traditional usage of M-q, 00:21:52.633 --> 00:21:54.200 and it still works in text-mode buffers, 00:21:54.233 --> 00:21:55.859 but in prog-mode buffers-- 00:21:55.860 --> 00:22:00.100 so any major mode inheriting prog-mode-- 00:22:00.100 --> 00:22:02.233 M-q will now by default be bound 00:22:02.266 --> 00:22:09.779 to prog-fill-reindent-defun. To summarize the point, 00:22:09.780 --> 00:22:13.433 if you are editing a string or a comment, 00:22:13.466 --> 00:22:16.039 then the comment will be filled. 00:22:16.040 --> 00:22:19.100 But if you are outside of a comment or outside of a string, 00:22:19.100 --> 00:22:23.166 then the defun or the top-level construct 00:22:23.200 --> 00:22:26.159 in the programming language will be re-indented. 00:22:26.160 --> 00:22:34.099 Let's try that out with maybe some file I have open here. 00:22:34.100 --> 00:22:38.800 If I'm in this... Let's choose some function, 00:22:38.833 --> 00:22:40.733 let's take this for example. 00:22:40.766 --> 00:22:43.959 If we followed all of this again, 00:22:43.960 --> 00:22:47.400 and I press M-q in on this paragraph, 00:22:47.433 --> 00:22:49.433 then the paragraph gets re-indented. 00:22:49.466 --> 00:22:55.800 But if I'm down here and I choose to break the indentation 00:22:55.833 --> 00:22:58.166 and then press M-q, 00:22:58.200 --> 00:23:02.333 then as you see, it practically selected the defun 00:23:02.366 --> 00:23:03.566 and re-indented everything 00:23:03.600 --> 00:23:06.959 without having me to move the point around in the buffer. 00:23:06.960 --> 00:23:08.633 So I think that's a really nice feature, 00:23:08.666 --> 00:23:11.100 which a lot of people can appreciate. 00:23:11.100 --> 00:23:17.939 It's one of those niceties which comes from time to time. NOTE Wrapping up 00:23:17.940 --> 00:23:20.633 Right, so that was my overview 00:23:20.666 --> 00:23:22.600 of what's going to be new in Emacs 30. 00:23:22.633 --> 00:23:24.400 I hope that most people could take away 00:23:24.433 --> 00:23:25.579 something from this presentation 00:23:25.580 --> 00:23:28.900 and have something to look forward 00:23:28.900 --> 00:23:31.133 to try out after upgrading. 00:23:31.166 --> 00:23:33.833 As mentioned initially, as of recording, 00:23:33.866 --> 00:23:36.566 this release has not been completed yet. 00:23:36.600 --> 00:23:38.833 If this is still not the case 00:23:38.866 --> 00:23:40.233 when you're seeing this video, 00:23:40.266 --> 00:23:43.833 please consider downloading and building Emacs 30 yourself. 00:23:43.866 --> 00:23:48.200 If you have any issues, which is always the case, 00:23:48.233 --> 00:23:56.439 please report them to using report-emacs-bug. 00:23:56.440 --> 00:23:57.907 That will pop up a mail buffer, 00:23:57.908 --> 00:23:59.600 and then you can describe your issue and send them out. 00:23:59.633 --> 00:24:01.800 All bug reports are valuable, 00:24:01.833 --> 00:24:04.433 even if they are false positives or duplicates-- 00:24:04.466 --> 00:24:05.233 it doesn't matter-- 00:24:05.266 --> 00:24:08.533 because when you take the time to submit a bug report, 00:24:08.566 --> 00:24:12.233 which describes something that's specific to your setup, 00:24:12.266 --> 00:24:16.700 which the developers might not have noticed or known about, 00:24:16.700 --> 00:24:19.133 then you are certainly helping out a lot of other people 00:24:19.166 --> 00:24:21.766 which might run into the same issue in the future. 00:24:21.800 --> 00:24:23.200 Especially with upgrades, 00:24:23.233 --> 00:24:26.566 it would be nice to figure out small problems 00:24:26.600 --> 00:24:30.800 which make upgrading difficult for some people. 00:24:30.833 --> 00:24:34.700 The ideal is, of course, to have no issues 00:24:34.700 --> 00:24:37.199 when upgrading from one version to another. 00:24:37.200 --> 00:24:39.566 Having said that, I thank you for your attention, 00:24:39.600 --> 00:24:43.766 and I'm saying goodbye.