Emacs 30 Highlights

Philip Kaludercic

Format: 25-min talk ; Q&A: BigBlueButton conference room
Etherpad: https://pad.emacsconf.org/2024-emacs30
Status: TO_CAPTION_QA

Talk

00:00.000 Introduction 01:41.800 Android 07:45.720 EditorConfig 09:27.310 use-package integration with package-vc 13:11.560 JSON 15:56.680 Native compilation 17:29.640 Tree-sitter 18:16.780 Completion preview mode 19:34.233 package-isolate 21:16.920 Reindenting 23:17.940 Wrapping up

Duration: 24:55 minutes

Q&A

00:16.280 Q: which-key was a third-party package for a long time. Is there work to bring any other popular packages into core Emacs for Emacs 31+? (magit, counsel, etc) 04:06.467 Q: Any way to get the goodness of Emacs for android with this other stuff? 05:15.754 Q: Does package-vc download a tarball from the specified git repository or clone the repository itself? 06:37.970 How is the new behavior of M-q in prog-mode (prog-fill-reindent-defun or something like that) different from the behavior of C-M-q (indent-pp-sexp) in older Emacs versions? 08:33.144 Q: Any plans for Emacs running in iOS? 09:08.648 Q: I am worried about the situation on non-free systems. There was talk about the Windows and the macOS versions being as good as unmaintained. Where do we go from here? 11:35.280 Q: Is there a best practice on what Org to use when following emacs-latest?

Listen to just the audio:
Duration: 23:36 minutes

Description

Discussion

Questions and answers

  • Q: which-key was a third-party package for a long time. Is there work to bring any other popular packages into core Emacs for Emacs 31+? (magit, counsel, etc)
    • A: One package that was being discussed was macrostep (https://github.com/emacsorphanage/macrostep).
    • Magit is an ongoing discussion, but I don't know of any concrete progress.  Generally the best way to help is just to send a message to emacs-devel and keep to it.  Feel free to CC me to help!
  • Q:When thinking about using Emacs on android I start realising all the other software I also want with it. For example pdf-tools wants a small additional emacs specific program to be installed and notmuch wants notmuch. Any way to get the goodness of Emacs for android with this other stuff? Using nixos or guix, nix-on-droid to make an apk with extra stuff?
    • A:
  • Q: Does package-vc download a tarball from the specified git repository or clone the repository itself?
    • A: Clones the repository (that's the -vc in the name)
    • Compare with vc-clone (which is now exposed as an interactive command compared to before)
  • Q: How is the new behavior of M-q in prog-mode (prog-fill-reindent-defun or something like that) different from the behavior of C-M-q (indent-pp-sexp) in older Emacs versions?  (My apologies if indent-pp-sexp is not bound to C-M-q by default, I can't tell)
    • A: The difference is in the behavior when the cursor is inside a string.
  • Q:Any plans for Emacs running in IOS?
    • A: Probably not. Emacs support on Android is completely free. To my understanding, you need Xcode to build iOS stuff.
  • Q: I am worried about the situation on non-free systems. There was talk about the Windows and the macOS versions being as good as unmaintained. Where do we go from here? I gather that most users of Emacs are still on non-free platforms and will remain to be there.
    • A: I don't know about the last point if that's true; there are no statistics on the matter. I know Corwin is involved in the Windows port. Someone has to do the work. Eli is on a Windows XP system. As long as he's doing that, there's going to be Windows some way or another.
      • Corwin: accessibility issue (ex: maybe that XP system is what they can afford, or what they need to use for work) Concerning when we hear about black holes in the braintrust for support for these things.
      • And the same thing applies for macOS.
  • Q: I'm a bit confused about what version of org I should write towards, because there's org (in emacs) org (in elpa) org (in org) etc... Is there a best practice on what-org-to-use when following emacs-latest?
    • A: Depends on... my rough heuristic is if you're using the latest features of Org, use the one on ELPA, maybe. Personally I just use the one bundled in Emacs.

Notes and feedback

  • Loving to use all of these changes.
  • Graphical Emacs in Android is awesome
    • that seems more usable than i thought it would be
    • swipe left/right for next buffer?
    • I was able to load my custom configuration on Android by traversing through the directories with M-x shell.
  • Oooo, which-key is so helpful for beginners. It fits right in to the core. Great addition!
    • that would have saved me a lot of time years ago haha
  • An alternative to both which-key and prefix-help-command (which pkal is demoing right now) is embark-prefix-help-command
    • thanks, I was not aware of it (I still "M-x embark-..." or preset bindings from completion/vertico candidates) - how does it differ from prefix-help-command?
    • This is my favourite change, but not all packages are compatible with it...
    • It offers a completing-read interface to complete the partial command.
    • completion within completion within completion within.. love it
    • (setq prefix-help-command 'embark-prefix-help-command)
    • Will try it for a while, thanks for the pointer
    • it's completion all the way down
  • use-package :vc is much welcome! (as one coming from Clojure's deps, such a breeze)
  • great talk!
  • YouTube comment: Really good rundown of the changes. Thank you! Looking forward to start using 30.
  • YouTube comment: I would like to know when EMACS 30 will be officially released? I looked around Arch repos and EMACs website; I just see EMACS 29.4. Also I did install from the Google Store the EMACs editor on my Samsung S22, it works but one problem is I can't access file directors in the home directory. It is very annoying, yet the EMACs editor works well. There is so much security and permissions on these Android devices, makes it very annoying just to open a text file.

Transcript

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

Captioner: anush

Q&A transcript (unedited)

You sound great. And on the stream, my eyeball says it looks great with Leo doing the streaming. So I say let's dive right in. You got a long, huge line. And in order to be a little more dialectical, I'll be reading the questions. So first
[00:00:16.280] Q: which-key was a third-party package for a long time. Is there work to bring any other popular packages into core Emacs for Emacs 31+? (magit, counsel, etc)
question, which key was a third party package for a long time? Is there work to bring any other popular packages into the core of Emacs for Emacs 31 plus, like Magit or Counsel? Uh, right. I already answered that one on the, as you can see, uh, right. Yeah. Do you want to quickly read the answer so that everyone, I just can read it out again. Um, as far as I remember, the one package that was being discussed just around the time that the Emacs 30 branch was cut was macro step. That's the package that was like, does an overlay, uh, replaces a macro with the macro expansion using overlays. So you don't have to pop up another buffer, modified, modified current buffer. But we didn't manage to address all the concerns in time for the Emacs 30 cuts and I believe it's sort of stagnated around that but it might be picked up anytime someone mentions it on Emacs Devil again. Another package question mentioned was Magit. That's a constant discussion regarding Magit. And actually, from the top of my head, I can't recall if Magit is on NonGNU ELPA or GNU ELPA right now. It's still on NonGNU ELPA. For those who don't know, only packages which are in ELPA are considered for addition, considered to be added to the Emacs core, to be bundled along with Emacs. And then there's another totally parallel discussion about having a sort of fat Emacs distribution, I call it fat Emacs distribution, where Emacs comes with a lot of ELPA packages or the pre-installed by default. Part of Emacs itself. Yeah. Maybe I could jump in with an active listening style, you know, kind of follow up question almost. You know, I understand the kind of different repositories. We have things that aren't maintained by GNU at all, you know, most notably MELPA. And then we have kind of NonGNU ELPA, which is sort of an entryway project where it's not necessarily curated, but there'll be some advice given, which you can take or leave. And that's the repository where anything that was the newer repository that represents, you know, help, you know, help, help supplied from GNU. And then there's the, actually the GNU, the GNU ELPA, what most of us are used to calling just ELPA. And that's what you're talking about there when you say, I mean, all packages on ELPA are officially considered to be part of Emacs, they're licensed under the same conditions as Emacs itself, same license, same everything. And they're more likely to be, to drop, to kind of be dropping patched. Oh yeah, it's time for this to move to core. Is that right? They have the legal conditions for that to be done. Everything's necessary from a paperwork standpoint. I mean, but other than that, there's not really a big difference between GNU ELPA and NonGNU ELPA. It's really just the main thing is this copyrights notice. So if you want to add a package to ELPA, to GNU ELPA, then all significance contributors have to have signed the FSF copyright assignment and the package script, actually the ELPA build script, checks if the copyright lines are all attributed to the Free Software Foundation. But that's not going to attach, right? So because that's not in place, it'd be a lot more work to merge it to core. I didn't hear the beginning. Nevermind. I think I understood. You made your point well. Okay. All right, moving on to the second question.
[00:04:06.467] Q: Any way to get the goodness of Emacs for android with this other stuff?
When thinking about using Emacs on Android, I started realizing all the other software I also want on it. For example, PDF Tools wants a small additional Emacs-specific program to be installed on, and notmuch obviously wants notmuch. Any way to get the goodness of Emacs for Android with this other stuff, using either Nix OS or Guix or nix-on-droid to make an APK with extra stuff? Are you familiar with this topic? Absolutely not. The extent to which I have used Emacs on Android was entirely demonstrated in this video, I think. In my previous video. I mean, I know it does a few scrolling stuff, but I have no idea how external stuff, because I mean, Android is, it's a Unix or it's a Linux based system, but it's really heavily modified to the preferences of Google, which includes not being able to have your own software on it. Yeah, definitely. All right, moving on to the next question. Does package-vc... Oh, no, that's fine. I mean, you can't answer all the questions. I mean, it wouldn't be fun for me otherwise.
[00:05:15.754] Q: Does package-vc download a tarball from the specified git repository or clone the repository itself?
Does package-vc download a tarball from the specified Git repository or clone the repository itself? It clones the repository. That's the VC part in the name. package-vc uses VC, the C-x v stuff. In Emacs 29, there's a new command called vc-clone, which in Emacs 31, it was actually exposed as an interactive command. And when you clone the repository, or when you, you can give it any URL of a Git repository or a CVS repository or subversion repository. Interestingly enough, most people only use Git, but anything that's, that implements this clone command for VC, and it could download it. So there's no tarballs involved. Which is also, one should emphasize, part of the difficulty of VC packages because when you have version control and you want to upgrade it, it might be that the upstream did a force push. For that, you make local changes and then you have to merge them upstream with the upstream changes when fetching stuff. It's one of the big downsides of version-controlled stuff, and I'm saying this as the guy who actually wrote package-vc. There's times to use it, there's advantages to it, but that's something you should keep in mind, why tarballs are interesting to have, in my opinion. Okay.
[00:06:37.970] How is the new behavior of M-q in prog-mode (prog-fill-reindent-defun or something like that) different from the behavior of C-M-q (indent-pp-sexp) in older Emacs versions?
How is the new behavior of M-q in prog mode, prog-fill-reindent-defun or something like that, different from the behavior of C-M-q, i.e. indent-pp-sexp in older Emacs version? My apologies if indent-pp-sexp, it's really tough to read M-x commands out loud. It's not bound to C-M-q by default, I can't tell. Let me try that command out because I've never tried it, never used it before. You know, that isn't bound by default. I bind that up myself and I have that binding. I think that's, that's not right. It says so. I mean, I'm currently executing it here in Emacs and it says you can also run the commands indent-pp-sexp with M-q, C-M-q. Apparently it is. I mean, I didn't set it myself. I don't know what's up with that. to try and move it. And then each line started with points or pretty printed. I mean, the difference, the main difference between that and the command highlighted, what's the name again? I forget it all the time. The prog-mode command. prog-fill-reindent-defun is that it checks if it's in a string or not. If it's in a string or if it's in a comma, then it will refill. Otherwise, it's going to re-indent. That's, I think, as far as I see, that's going to be the main difference. If we have some long comments somewhere. Let's try that out. Yeah, that's the difference. I just, you can't see it, but I did try it. Okay, good. Thank you. You did a wonderful job describing visually what you're doing. All right, moving on to the next question, and we have about, we have just enough time to cover the last three questions, especially because the next one, I can pretty much surmise the answer.
[00:08:33.144] Q: Any plans for Emacs running in iOS?
Any plans for Emacs running on iOS? Probably not because it's not, I mean, as I emphasized in the video, the Emacs port in Android is completely free. And to my knowledge, that's not something that's currently possible with iOS. You need Xcode or something like that to build iOS stuff. So that's a big no-no. I mean, maybe Apple's going to change their mind on that one. Well, I won't be the one liaising with Apple to make sure that they do, but PR welcomes, I guess, or motivated folks welcome. Second to last question.
[00:09:08.648] Q: I am worried about the situation on non-free systems. There was talk about the Windows and the macOS versions being as good as unmaintained. Where do we go from here?
I am worried about the situation on non-free systems. There was talk about the Windows and the macOS versions being as good as unmaintained. Where do we go from here? I gather that most users of Emacs are still on non-free platforms and will remain to be there. I don't know about the last point, if that's true, because there's no statistics on that matter. But the main, I mean, someone has to, I know that Corwin is involved with the Mac, with the Windows stuff. Modestly. Sure, I'd love to jump in, but I'm far more interested in your thoughts than mine. Please, please continue. Someone has to do the work. Eli uses, as far as I know, Eli's on the Windows XP system. So as long as he's doing that, there's going to be Windows support for one form or another, or at least DOS. All right. And now you put a quarter in me, so I'll jump right back in. That's perfect for where I guess I would take the question. To me, it's an accessibility issue. Think about it this way. Maybe that Windows XP system is what someone can afford. Likewise, from a freedom versus I have to do my job and I have to use certain technology to do my job. Maybe Emacs is what somebody can afford right? It might be the only free tool that they use and they don't have a lot of choice about the operating system that they're in most of the day. In fact, somebody could be in the situation where their computing device at work is really their internet access, right? All of those situations are possible. Therefore, I tend to assume they all exist and when I ask, you know, how much It definitely is concerning when we hear about kind of black holes in the brain trust of something like support for the Windows port. I feel like I've heard a lot of people answering that call, but the importance of that is that it doesn't stop echoing, right? Free software goes as long as there are people that are irritated enough about something to sort of come hack on it. Yeah. And the same applies to Mac OS. But I don't know any concrete details about who's currently working on it. I can't recollect any details on who's currently working on what. Okay. And that leaves us with the last question of the day.
[00:11:35.280] Q: Is there a best practice on what Org to use when following emacs-latest?
I'm a bit confused about what version of Org that I should write towards because there's Org in Emacs, the one that ships built-in. There's the one in ELPA. There's the one in Org, probably the Org ELPA, I assume. Is there a best practice on what Org to use when following Emacs latest? when following us latest. It depends on, I think, my rough heuristic is if you do use Org a lot and if you follow the newest features, then use the version on Elpa, because the Elpa version should be the most up-to-date one. The Org Elpa was deprecated, to my knowledge. If that seems true, please someone interrupt me before I make a fool of myself. No one's done that yet. I think a couple of years ago there were chats and then we deprecated the all contrib ELPA, but I think all the ELPA is still alive. I didn't know that about that. Okay, in that case, that relativizes how absolute my answer is. Personally, I just use the version in Emacs, which is bundled with Emacs, which is regularly updated on master whenever there's a release. But that might take maybe, it might be a short time behind the ELPA version, or the other ELPA, the Org ELPA, which we mentioned. But I'm a very light Org mode user, so please don't take my word for that one. No, and I'm happy to come to you. Yeah. I feel like we lost Leo again. OK. Well, that's all right. I wanted a bite at that, Apple. I'm a little bit. Yeah, I also describe myself as a light org user, but somehow your comment made me think, well, maybe I do use it just a little bit more than you, Philip. From my standpoint, I'm using it as a technical basis for dungeon mode in order to keep the game notes for the games that are made using this game engine I'm making that I talked about a few years ago. As soon as you said technical grounds, you definitely use it more. Right, right. So I've studied its internals a bit, and I have my own thoughts about this or that. But of course, I'm rolling with the punches because I'm just grateful that the bear dances. What an amazing thing is Org Mode. But Leo knows far more than me, conveniently having his stage right here, so he can't defend himself from this. But I've had thoughts around this space. Are you back, Leo? Yeah, sorry, I'm back. You save us all. Maybe closing remarks. I was trying to clear my throat to be very inconspicuous about me coming back, but apparently I was ousted. Yeah, I was trying to answer the question and I was trying to desperately save you from answering, Philip, because yes, the thing about Org Mode is that if you are the kind of people who tend to check out master on Org Mode, generally it's roughly pretty stable. Like when we were working with Org Element and stuff like this, Perhaps there were some elements of stability which weren't there quite yet, but usually now it's pretty stable. So I think that if you are really excited about contributing to Org Mode and stuff like this, I think there isn't all that many risks to just checking out Org Mode Master, so cloning the repository and just keeping up to date. Otherwise, ELPA is a fairly safe bet if you want to have the latest stable version. And we've got a question about [??] as with Emacs itself. You can follow whatever is published in your package archives or in your system distribution package manager. You can build it yourself if you want to contribute and fix bugs, add features, and so on. Yeah, and I don't think perhaps a little more with Emacs, because the features that tends to get introduced in Emacs are slightly more wild. Not wild in the sense that they are less stable, but wild in the sense that they tend to change a lot more stuff. The core of Org, at least during Bastien's maintenance ship, was very stable when you think about it. So things might change with Ihor right now in terms of how he wants to change some of the core behaviors, but it's usually pretty stable. And whether you use the latest major version, the latest minor version, things are probably going to be pretty stable. It's like you heard me while you were offline. And I do agree with that, in case you might have heard both our remarks and think we're talking different angles. Actually, I think we would tend to agree on this, Leo and I. For the record, when I'm saying, oh, I have to go keep up with org, that's because org grows behaviors that I've got my own. I had to figure out at some point my own way to do it, and now I'm learning how it's done, right? So I'm like, in my abstraction, blah, right? And those conversations usually end at, and somebody else took the time to figure out how to actually make Emacs do that. Go be quiet. And I do, and I do consider that under Bastien's tenure, it has been quite stable. We might notice the occasional like, oh, this highlights now and that didn't, right? But very often, very infrequently is it breaking my workflow as a user, any of it. It's interesting to me that this mirrors my experience with Emacs itself, where I think, in my perception, Emacs master is very stable and I might notice the slight changes between git pulls. But otherwise, in my experience, Org mode suddenly changes something, I don't know what changed or what's going on or what caused it, and it seemed... I perceive it as being a sudden uncontrolled change or something. I think that's apt. Right. That gets right at it. If we're following, if we're pulling for more pretty regularly, cronjob every night or pulling a few times a day or something like that, we're going to the internals yeah, we'll have a different experience than, you know, if we only remember to update Org once every four months. It really pays to stick with everything. And suddenly lots of things might change. Whatever broke in my own config, right? And so a lot of, like a lot of things within Emacs, but also within the free software tool chain, it's how much you're going to invent in the config, invest in the config, might limit you know, and maintaining your config may limit the depth of how far it makes sense for you to go with the tool at any given point in time. Actually just looked up my org config and it's four, I said four options, user options. So that's, if that's the measurements of org expertise, that's my level, it's four. That's all good then. Four of four, I'm assuming that is, right? Four of what? What was the metric there, four of like a thousand? Four out of the number of user options that Word provides. Oh, okay, I see. Four, yeah, more like 10,000. I'm there. Yeah. All right. On that note, I suggest we move to what's close because it's fairly late for me and I need to sleep. And Philip, I think it's pretty late for you as well, isn't it? I'm in Germany, so it's about... So it is pretty late. It's the same time zone as me. It's 11 p.m. for you. Truly, yeah. Yeah, so I suggest we both take the chance to go to bed as soon as we can. But Philip, thank you so much for both the presentation and also the answers that you provided to us and the nice little chat we had at the end. We look forward to seeing you again next year, perhaps for Emacs 31. I'm not sure. I was chatting with wasamasa trying to make prognostics about when Emacs 30 is going to be released. There's a pre-release coming soon. I should have mentioned that earlier. Well, there you go. Gone. All right. Well, thank you so much, Philip. We'll be moving towards close. Give us about two minutes to get set up in the other room. And Philip, we'll see you next time. Goodbye. Bye-bye. Thank you.

Questions or comments? Please e-mail emacsconf-org-private@gnu.org