WEBVTT captioned by sachac NOTE Introduction 00:00:00.000 --> 00:00:04.679 Hello. If you're listening to this talk, 00:00:04.680 --> 00:00:06.239 then you should be at least a bit interested 00:00:06.240 --> 00:00:09.199 in Org mode, which is fantastic 00:00:09.200 --> 00:00:11.252 because there have been quite a few 00:00:11.253 --> 00:00:14.599 interesting developments over the past year or so. 00:00:14.600 --> 00:00:19.399 I'm Timothy, as you may have gathered from the last talk, 00:00:19.400 --> 00:00:21.799 and I'm also quite involved with the Org project, 00:00:21.800 --> 00:00:23.999 so I'd like to go through a few of those developments 00:00:24.000 --> 00:00:27.439 over the past year or so and give you a few hints as well 00:00:27.440 --> 00:00:32.079 as to what potentially lies around the corner with Org mode. NOTE Project housekeeping 00:00:32.080 --> 00:00:35.879 The starters, slightly on the more boring side 00:00:35.880 --> 00:00:37.679 but rather significant change to the project, 00:00:37.680 --> 00:00:40.799 occurred with the housekeeping or organisation. 00:00:40.800 --> 00:00:43.519 The codebase for the Org project has actually shifted over 00:00:43.520 --> 00:00:46.799 from a self-hosted Gogs instance over to Savannah, 00:00:46.800 --> 00:00:49.719 which means it's now living right alongside 00:00:49.720 --> 00:00:51.519 the Emacs codebase. 00:00:51.520 --> 00:00:53.279 This has been accompanied by the creation 00:00:53.280 --> 00:00:58.219 of a whole bunch of Org-related repos under 00:00:58.220 --> 00:01:03.359 Bastien's (Org's maintainer) personal sourceHut account. 00:01:03.360 --> 00:01:06.759 We've got the source of the website, the Org wiki Worg, 00:01:06.760 --> 00:01:08.799 as well as Org contrib. NOTE Continuous integration 00:01:08.800 --> 00:01:13.119 Another recent addition to this list of Org-related repos 00:01:13.120 --> 00:01:17.799 is the new Org mode tests--continuous integration. 00:01:17.800 --> 00:01:22.039 Now, this is rather important, because while we do recommend 00:01:22.040 --> 00:01:25.879 that all contributors actually run make tests 00:01:25.880 --> 00:01:29.799 before submitting patches to the Org project, 00:01:29.800 --> 00:01:31.279 this doesn't always happen. 00:01:31.280 --> 00:01:34.559 It can also actually be a bit harder than you expect 00:01:34.560 --> 00:01:35.719 to run the tests because there are a lot 00:01:35.720 --> 00:01:37.759 of trans-dependencies you get with Org; 00:01:37.760 --> 00:01:40.199 for instance, with all of the various Babel libraries 00:01:40.200 --> 00:01:42.599 which actually require other packages 00:01:42.600 --> 00:01:46.079 or programming language to be installed on the system. 00:01:46.080 --> 00:01:50.079 Having a single self-contained test system 00:01:50.080 --> 00:01:53.319 to actually make sure that Org can be regularly 00:01:53.320 --> 00:01:57.519 and thoroughly tested should be a great help for actually 00:01:57.520 --> 00:02:04.679 ensuring the quality of the contributions. NOTE Funding contributors 00:02:04.680 --> 00:02:07.079 The funding structure for Org has also undergone a bit 00:02:07.080 --> 00:02:10.559 of a shift. Historically, we've just directed everybody 00:02:10.560 --> 00:02:14.199 who's interested in financially supporting the Org project 00:02:14.200 --> 00:02:18.639 to the maintainer Bastien's personal GitHub sponsors 00:02:18.640 --> 00:02:22.399 and LibrePay accounts. Now, early this year, 00:02:22.400 --> 00:02:27.519 Bastion has created the Librepay Org mode team account, 00:02:27.520 --> 00:02:29.039 which means that you can actually now 00:02:29.040 --> 00:02:33.159 support the Org project as opposed to 00:02:33.160 --> 00:02:34.479 the person leading the Org project. 00:02:34.480 --> 00:02:39.159 Currently, this just distributes donations between Bastien, 00:02:39.160 --> 00:02:42.079 Ihor, and myself. However, the idea is that 00:02:42.080 --> 00:02:45.039 as the active contributors for the Org project 00:02:45.040 --> 00:02:50.839 come and go over time, the list of people on this team 00:02:50.840 --> 00:02:56.999 can be changed as seems sensible. The hope here is that 00:02:57.000 --> 00:03:00.159 it will simplify both how easy it is 00:03:00.160 --> 00:03:02.559 to actually financially support the Org project 00:03:02.560 --> 00:03:04.359 as well as how easily people contributing 00:03:04.360 --> 00:03:09.599 to the Org project can be supported. 00:03:09.600 --> 00:03:13.479 If you're interested in supporting the Org project, 00:03:13.480 --> 00:03:15.439 there's never been a better time than now 00:03:15.440 --> 00:03:16.919 to have a look at this 00:03:16.920 --> 00:03:23.159 and let anybody who might also might be interested know. 00:03:23.160 --> 00:03:25.279 Hopefully, this leads to a healthier funding structure 00:03:25.280 --> 00:03:28.199 that will scale better into the long term 00:03:28.200 --> 00:03:32.559 and thus better support the work that happens with Org. NOTE New features 00:03:32.560 --> 00:03:37.079 Now, the project itself has of course also seen quite a bit 00:03:37.080 --> 00:03:38.519 of development over the past year. 00:03:38.520 --> 00:03:44.159 We've had about 800 comments from 80 contributors. 00:03:44.160 --> 00:03:46.519 Within these comments, there's been a lot of polishing 00:03:46.520 --> 00:03:48.759 quality-of-life improvements, 00:03:48.760 --> 00:03:50.519 and also quite a few new features. 00:03:50.520 --> 00:03:52.799 Now, I haven't got nearly enough time 00:03:52.800 --> 00:03:54.159 to go through this exhaustively, 00:03:54.160 --> 00:03:58.639 so we're just going to go through a quick highlight reel. NOTE An assortment of export improvements 00:03:58.640 --> 00:04:00.239 There's a collection of export improvements 00:04:00.240 --> 00:04:04.319 from things which affect all export backends, 00:04:04.320 --> 00:04:07.319 like including remote content 00:04:07.320 --> 00:04:09.599 and adding new things like DOI links 00:04:09.600 --> 00:04:11.519 and support for encrypted Org files, 00:04:11.520 --> 00:04:14.679 as well as a whole lot of export-backend-specific changes. 00:04:14.680 --> 00:04:17.159 For example, quite a few backends-- 00:04:17.160 --> 00:04:18.519 I've mentioned the LaTeX one here, 00:04:18.520 --> 00:04:23.119 but also others such as Texinfo--have now got 00:04:23.120 --> 00:04:26.799 rich support for various types of attributes and objects. 00:04:26.800 --> 00:04:31.919 The HTML backend has had a few things boosted up and well, 00:04:31.920 --> 00:04:33.519 if you want to see the full list, 00:04:33.520 --> 00:04:36.519 just take a look at the release notes. NOTE A collection of babel improvements 00:04:36.520 --> 00:04:39.319 We've also seen a similar collection of improvements 00:04:39.320 --> 00:04:43.519 with the Babel backends. Once again, this is scattered-- 00:04:43.520 --> 00:04:46.519 or well, it can be split into two sets of changes. 00:04:46.520 --> 00:04:49.599 There's some which affect all of Babel, essentially. 00:04:49.600 --> 00:04:52.599 For instance, the new syntax of parsing 00:04:52.600 --> 00:04:56.479 the raw content of code blocks, or the changes with Noweb. 00:04:56.480 --> 00:05:01.919 For example, :noweb-prefix is a new option that can be used. 00:05:01.920 --> 00:05:03.239 And then there's also a collection 00:05:03.240 --> 00:05:07.439 of backend-specific changes. So ASCII graphics with PlantUML 00:05:07.440 --> 00:05:12.279 or enhanced return capabilities with the ob-python library. NOTE A multitude of general org-mode improvements 00:05:12.280 --> 00:05:17.479 And then of course, as before, a whole collection 00:05:17.480 --> 00:05:19.839 of more changes which you can find in the release notes. 00:05:19.840 --> 00:05:22.839 Last but by no means least, 00:05:22.840 --> 00:05:26.239 there have been quite a few changes within the rest of Org. 00:05:26.240 --> 00:05:30.839 So this is, once again, far too many things to list, 00:05:30.840 --> 00:05:33.759 but it's things like improved refiling, 00:05:33.760 --> 00:05:36.639 capture templates, image preview sizing, 00:05:36.640 --> 00:05:38.159 clocktable settings, agenda tweaks, 00:05:38.160 --> 00:05:41.159 and well, a whole lot more. 00:05:41.160 --> 00:05:45.039 Yes, basically, the essence of what's here 00:05:45.040 --> 00:05:47.999 is a lot of little changes 00:05:48.000 --> 00:05:50.799 which just address particular use cases in ways 00:05:50.800 --> 00:05:55.052 that I don't think anybody's going to be seeing 00:05:55.053 --> 00:05:55.786 the impact of all of them, 00:05:55.787 --> 00:05:57.559 but I think most people should at least 00:05:57.560 --> 00:06:00.119 find one or two things 00:06:00.120 --> 00:06:04.159 which actually improve their own usage. NOTE Citations 00:06:04.160 --> 00:06:06.079 Now these are the sort of assorted 00:06:06.080 --> 00:06:07.399 relatively minor improvements, 00:06:07.400 --> 00:06:09.959 but there are also some major ones. 00:06:09.960 --> 00:06:12.159 And one in particular, citations. 00:06:12.160 --> 00:06:15.879 So I think this has been, at this point, 00:06:15.880 --> 00:06:17.079 over a decade in the making, 00:06:17.080 --> 00:06:21.919 but Org finally has first-class support for citations. 00:06:21.920 --> 00:06:23.759 And I have to say, it is marvellous. 00:06:23.760 --> 00:06:27.239 You'd hope so, after the labour. I think it is. 00:06:27.240 --> 00:06:30.119 It can be said that it's actually worth the wait. 00:06:30.120 --> 00:06:31.679 I think out of the various options you've got now, 00:06:31.680 --> 00:06:34.279 (for example, the way that Pandoc 00:06:34.280 --> 00:06:35.599 and Markdown otherwise[??] do it) 00:06:35.600 --> 00:06:40.519 Org has a fantastically succinct and flexible 00:06:40.520 --> 00:06:45.959 syntax for citations, which scales really well for all sorts 00:06:45.960 --> 00:06:47.199 of different use cases. 00:06:47.200 --> 00:06:51.159 Additionally, on the backend side of things, 00:06:51.160 --> 00:06:55.359 we've now got a generalised way for handling citations 00:06:55.360 --> 00:06:57.839 which has been quite helpful for the--I think 00:06:57.840 --> 00:07:00.359 I could say rather rapid development 00:07:00.360 --> 00:07:03.279 of multiple citation backends for Org. 00:07:03.280 --> 00:07:07.639 And I think it's just fantastic, really, seeing 00:07:07.640 --> 00:07:09.839 how quickly Org has gone 00:07:09.840 --> 00:07:12.239 from having no support for citations 00:07:12.240 --> 00:07:13.239 at the start of this year 00:07:13.240 --> 00:07:17.559 to what can be described as 00:07:17.560 --> 00:07:20.199 a wonderfully rich and flexible support 00:07:20.200 --> 00:07:23.559 with, well, multiple backends for citations. 00:07:23.560 --> 00:07:27.519 I think that's something that we can really be proud of. 00:07:27.520 --> 00:07:30.039 And it's been a fantastic contribution 00:07:30.040 --> 00:07:31.599 for everybody involved in this process. NOTE Quality of life improvements 00:07:31.600 --> 00:07:36.119 Okay, so we've had features. 00:07:36.120 --> 00:07:38.039 There have also been a whole lot of 00:07:38.040 --> 00:07:39.559 quality of life improvements. 00:07:39.560 --> 00:07:43.479 Once again, many more than I can reasonably mention here. 00:07:43.480 --> 00:07:46.079 So I'm just going to flick it through 00:07:46.080 --> 00:07:48.319 a few of them. A few big ones though, NOTE Org fold 00:07:48.320 --> 00:07:52.519 Ihor is responsible for three lovely developments with Org, 00:07:52.520 --> 00:07:55.119 one of which is Org fold. So this is a generalisation 00:07:55.120 --> 00:07:57.239 of the way that content is folded in Org. 00:07:57.240 --> 00:08:00.679 And I think quite a few of you will actually underestimate 00:08:00.680 --> 00:08:01.679 how much can be folded in Org. 00:08:01.680 --> 00:08:03.039 It's not just a matter of headlines. 00:08:03.040 --> 00:08:07.919 It's headlines, code blocks, lists, environments, 00:08:07.920 --> 00:08:10.519 all sorts of things can actually be folded in Org. 00:08:10.520 --> 00:08:14.679 And the introduction of Org fold is important 00:08:14.680 --> 00:08:18.919 for two reasons. One is that it has allowed for 00:08:18.920 --> 00:08:21.479 text-property-based folding, 00:08:21.480 --> 00:08:24.479 which in Emacs versions less than 29 00:08:24.480 --> 00:08:27.719 has a huge difference in performance, 00:08:27.720 --> 00:08:29.959 which is particularly apparent with larger files. 00:08:29.960 --> 00:08:32.639 The second significant thing about this is that 00:08:32.640 --> 00:08:36.479 it now actually provides a more general way 00:08:36.480 --> 00:08:39.879 to actually describe changes to the folding structure. 00:08:39.880 --> 00:08:42.559 So before there was direct modification of 00:08:42.560 --> 00:08:45.959 messing with overlays scattered around the Org code base. 00:08:45.960 --> 00:08:49.399 Now we have a much more well organised system 00:08:49.400 --> 00:08:53.319 where we use Org fold to say what is and isn't folded 00:08:53.320 --> 00:08:54.799 and to manage the state of all of that, 00:08:54.800 --> 00:08:59.239 which is, I think, just from a sort of design, 00:08:59.240 --> 00:09:02.479 sort of project design approach, a much better system. NOTE Org element cache 00:09:02.480 --> 00:09:06.599 We've also got the Org element cache by Ihor. 00:09:06.600 --> 00:09:09.239 This is actually something which was discussed 00:09:09.240 --> 00:09:12.039 quite a while ago, but has somewhat stalled 00:09:12.040 --> 00:09:14.679 due to the difficulty of cache invalidation. 00:09:14.680 --> 00:09:17.279 Ihor has sunk a tremendous amount of effort into this 00:09:17.280 --> 00:09:19.759 and has improved it to the point 00:09:19.760 --> 00:09:21.799 where we've now actually been able to 00:09:21.800 --> 00:09:25.639 enable this by default. So what this basically does is 00:09:25.640 --> 00:09:27.999 it records lots of information 00:09:28.000 --> 00:09:30.159 about the structure of the Org document 00:09:30.160 --> 00:09:34.119 and allows for, well, with the appropriate modifications 00:09:34.120 --> 00:09:37.359 that Ihor has also made throughout the Org element library 00:09:37.360 --> 00:09:41.559 to use this information to speed up various operations 00:09:41.560 --> 00:09:44.879 based on the Org document syntax tree. 00:09:44.880 --> 00:09:48.279 And so this has been quite-- 00:09:48.280 --> 00:09:49.839 the improvements have been scattered all over the place, 00:09:49.840 --> 00:09:52.719 but for a good example for libraries 00:09:52.720 --> 00:09:57.719 or anybody who's wanting to quickly map over Org elements 00:09:57.720 --> 00:10:00.639 is `org-element-cache-map', which now provides 00:10:00.640 --> 00:10:04.559 a much, much faster way to map over 00:10:04.560 --> 00:10:07.359 all of the Org elements in a document. NOTE Org persist 00:10:07.360 --> 00:10:10.799 This also ties into the third major feature from Ihor 00:10:10.800 --> 00:10:13.919 which I'd like to mention, which is Org persist. 00:10:13.920 --> 00:10:17.959 So this provides a method of persisting values 00:10:17.960 --> 00:10:20.279 across Emacs sessions, basically saving them 00:10:20.280 --> 00:10:21.799 to a file somewhere and loading them. 00:10:21.800 --> 00:10:25.719 Now this works for Elisp values and it also works for files, 00:10:25.720 --> 00:10:29.679 which we made use of with the improved capabilities 00:10:29.680 --> 00:10:32.479 for remote files and exports. 00:10:32.480 --> 00:10:35.799 This has also been used with the `org-element-cache' data. 00:10:35.800 --> 00:10:37.479 So now, if you've got a massive Org file 00:10:37.480 --> 00:10:41.159 and you open it once, that data can be saved to 00:10:41.160 --> 00:10:44.319 with the Org element cache to Org persist, 00:10:44.320 --> 00:10:46.679 and the next time you load this file 00:10:46.680 --> 00:10:47.919 in another Emacs session, 00:10:47.920 --> 00:10:50.959 we can just start with the cached data 00:10:50.960 --> 00:10:53.119 instead of having to construct everything from scratch, 00:10:53.120 --> 00:10:56.439 which is quite nice. Once again, a change which 00:10:56.440 --> 00:10:57.719 much like the other ones, 00:10:57.720 --> 00:11:00.359 we will see more of an impact in larger files, 00:11:00.360 --> 00:11:02.719 but a very welcome one everywhere. NOTE More careful resource downloading 00:11:02.720 --> 00:11:06.799 Now with remote files, there's also been the beginnings 00:11:06.800 --> 00:11:09.239 of a bit of an effort with Org 00:11:09.240 --> 00:11:13.119 to improve the approach we have to safety. 00:11:13.120 --> 00:11:14.999 So in this case previously, 00:11:15.000 --> 00:11:17.639 Org would unconditionally download 00:11:17.640 --> 00:11:19.559 all the remotes of files that's all referenced. 00:11:19.560 --> 00:11:23.759 And now, it's actually going to maintain a list of 00:11:23.760 --> 00:11:25.519 sort of safe resources and prompt you 00:11:25.520 --> 00:11:26.639 when it's surprised by something, 00:11:26.640 --> 00:11:29.886 to work out whether it should 00:11:29.887 --> 00:11:31.839 just download this one resource, 00:11:31.840 --> 00:11:35.279 mark the whole domain as safe, and a few other options. 00:11:35.280 --> 00:11:36.759 We're also going to probably see 00:11:36.760 --> 00:11:39.079 a similar approach extend to, for instance, 00:11:39.080 --> 00:11:40.199 bits of Babel execution in the future. NOTE Bug fixes 00:11:40.200 --> 00:11:45.359 Okay bug fixes. It will be remiss of me not to mention that 00:11:45.360 --> 00:11:46.919 along with all of the features 00:11:46.920 --> 00:11:49.359 and quality of life improvements, 00:11:49.360 --> 00:11:51.879 there has been a huge pile of bug fixes. 00:11:51.880 --> 00:11:57.319 I think the best way to actually get a look at this 00:11:57.320 --> 00:11:59.039 would be to look at the release notes 00:11:59.040 --> 00:12:00.599 or maybe even the actual commit log, 00:12:00.600 --> 00:12:04.119 but you could also just take my word and say that 00:12:04.120 --> 00:12:05.639 there have been a whole load of them 00:12:05.640 --> 00:12:11.599 over the past year. So just yes, the code base, I think, 00:12:11.600 --> 00:12:15.799 is just gradually getting into better and better shape. NOTE Asynchronous session evaluation 00:12:15.800 --> 00:12:18.199 Asynchronous session evaluation is I think possibly 00:12:18.200 --> 00:12:19.679 the final quality-of-life improvement 00:12:19.680 --> 00:12:22.119 I want to mention. This came early in the year, 00:12:22.120 --> 00:12:24.639 just with ob-python, and it's been delayed 00:12:24.640 --> 00:12:26.479 because in order to actually make it work, 00:12:26.480 --> 00:12:29.399 they've required some fundamental changes to the way 00:12:29.400 --> 00:12:31.079 that ob-comint works. 00:12:31.080 --> 00:12:33.599 Now that's been implemented, 00:12:33.600 --> 00:12:36.679 we've since seen support extended to ob-R, 00:12:36.680 --> 00:12:38.719 and hopefully, we'll see more languages join this list 00:12:38.720 --> 00:12:42.799 in the not-too-distant future. NOTE Nicer tangle mode syntax 00:12:42.800 --> 00:12:45.799 Now I guess one bonus which I tacked on just for fun is 00:12:45.800 --> 00:12:47.639 it's now more convenient than ever 00:12:47.640 --> 00:12:52.039 to actually specify the permissions for tangled files. 00:12:52.040 --> 00:12:54.999 Previously you had to give a list expression 00:12:55.000 --> 00:12:55.839 which should be evaluated. 00:12:55.840 --> 00:12:58.319 Now you can give it directly in octal form 00:12:58.320 --> 00:12:59.719 instead of being a list expression 00:12:59.720 --> 00:13:01.959 that produces an integer representation 00:13:01.960 --> 00:13:03.639 of the octal permissions. 00:13:03.640 --> 00:13:08.439 Or you can use ls style: rwx and dashes. 00:13:08.440 --> 00:13:13.079 Or even just chmod. I want to be able to execute this 00:13:13.080 --> 00:13:16.386 as a user, which will basically modify 00:13:16.387 --> 00:13:18.279 the default permission to add that capability. NOTE A flourishing ecosystem 00:13:18.280 --> 00:13:22.679 Alrighty. So that's the Org project itself, 00:13:22.680 --> 00:13:24.799 but there's also a whole ecosystem. 00:13:24.800 --> 00:13:27.439 So what have we got here? 00:13:27.440 --> 00:13:30.319 Well a whole bunch of Zettelkasten 00:13:30.320 --> 00:13:32.599 or personal-knowledge-base-type projects. 00:13:32.600 --> 00:13:36.239 One of which is logseq, so that's an online open source 00:13:36.240 --> 00:13:39.639 Zettelkasten which supports both Markdown 00:13:39.640 --> 00:13:41.799 and also Org mode as a first-class format. 00:13:41.800 --> 00:13:45.599 Then of course we have Org Roam, which provides 00:13:45.600 --> 00:13:48.879 a Zettelkasten built directly on top of Org within Emacs. 00:13:48.880 --> 00:13:51.639 Both of these are seen considerably interesting 00:13:51.640 --> 00:13:52.599 over the past year. NOTE Org-modern 00:13:52.600 --> 00:13:56.799 Moving on to visuals, minad has produced 00:13:56.800 --> 00:14:00.439 another lovely minad package in the form of org-modern 00:14:00.440 --> 00:14:04.559 which just spruces up the visuals of all documents 00:14:04.560 --> 00:14:09.519 and seems to have been quite well received recently 00:14:09.520 --> 00:14:10.119 since its release. NOTE citeproc-org 00:14:10.120 --> 00:14:13.159 Building on top of the citations from earlier, 00:14:13.160 --> 00:14:14.559 Andras Simonyi has produced 00:14:14.560 --> 00:14:16.559 the wonderful citeproc-org library, 00:14:16.560 --> 00:14:20.799 which, if you're not familiar, 00:14:20.800 --> 00:14:24.999 allows the capabilities of the citation style language 00:14:25.000 --> 00:14:26.639 which has now become something 00:14:26.640 --> 00:14:27.999 which is quite widely supported 00:14:28.000 --> 00:14:31.079 to be used for Org citation exports. 00:14:31.080 --> 00:14:33.799 This means that you've got access to I think at this point 00:14:33.800 --> 00:14:35.799 is it thousands or tens of thousands 00:14:35.800 --> 00:14:39.879 of different bibliography and citation formats 00:14:39.880 --> 00:14:42.919 which is obviously a huge boon to org citations. 00:14:42.920 --> 00:14:46.559 Lastly, just to be slightly critical, 00:14:46.560 --> 00:14:49.519 I'm actually going to mention the Neovim Org mode project, 00:14:49.520 --> 00:14:52.079 because I think this really shows the interest 00:14:52.080 --> 00:14:55.359 in Org as the format, beyond just Emacs. 00:14:55.360 --> 00:14:58.239 I think I haven't gone into it much here, 00:14:58.240 --> 00:15:00.919 but there's been quite a lot of development 00:15:00.920 --> 00:15:04.559 with external tools making use of the Org format. 00:15:04.560 --> 00:15:07.519 Clearly, we've done quite a few things right, 00:15:07.520 --> 00:15:11.599 and so I think it's interesting to see the interest 00:15:11.600 --> 00:15:13.319 that exists outside of Emacs, 00:15:13.320 --> 00:15:15.239 even without all the lovely tooling we've built, 00:15:15.240 --> 00:15:18.599 just out of appreciation of the formatting, its potential. 00:15:18.600 --> 00:15:21.079 Speaking of the format, though, 00:15:21.080 --> 00:15:24.159 we've also seen three new parsers on the scene this year. 00:15:24.160 --> 00:15:27.359 We've got one in Julia, Haskell 00:15:27.360 --> 00:15:28.599 and another one for Tree sitter. 00:15:28.600 --> 00:15:30.999 The last one, I think, is currently the least capable, 00:15:31.000 --> 00:15:32.479 but also potentially the most interesting 00:15:32.480 --> 00:15:36.959 in terms of what possibilities it allows for. 00:15:36.960 --> 00:15:42.079 Okay. So that's a quick speed run through 00:15:42.080 --> 00:15:44.039 some of the developments over the past year. NOTE Continuing work on the Org format 00:15:44.040 --> 00:15:47.959 What's coming next? So there's been 00:15:47.960 --> 00:15:50.999 quite a lot of work done with the Org syntax document. 00:15:51.000 --> 00:15:54.199 In fact, I've completely written it, 00:15:54.200 --> 00:15:57.239 and we've now taken it up to spec 00:15:57.240 --> 00:15:59.799 to actually accurately describe the way 00:15:59.800 --> 00:16:03.199 that the Org format is, as of Org 9.6. 00:16:03.200 --> 00:16:08.079 Now, I think this is quite an important document 00:16:08.080 --> 00:16:09.799 for the growth in parsing tools 00:16:09.800 --> 00:16:11.279 to help actually ensure 00:16:11.280 --> 00:16:16.439 that the way that external tools process Org 00:16:16.440 --> 00:16:20.079 is actually in sync with the way that Org mode does. 00:16:20.080 --> 00:16:22.559 I think it's worth doing everything we can, really, 00:16:22.560 --> 00:16:24.839 to avoid the sort of implementation drift 00:16:24.840 --> 00:16:27.719 that we've seen with Markdown. 00:16:27.720 --> 00:16:29.839 I don't want anything near that. 00:16:29.840 --> 00:16:32.486 This is also quite good for the Org format itself because, 00:16:32.487 --> 00:16:34.479 in the process of going through this sort of effort, 00:16:34.480 --> 00:16:38.199 it brings attention to irregularities in the syntax 00:16:38.200 --> 00:16:41.519 which you might want to resolve, and as well as 00:16:41.520 --> 00:16:43.919 helping the robustness of org mode itself. 00:16:43.920 --> 00:16:46.279 So ultimately, this is to everybody's benefit, really. 00:16:46.280 --> 00:16:51.799 It's also my personal hope that this might actually 00:16:51.800 --> 00:16:54.879 get to the point where we consider submitting this 00:16:54.880 --> 00:16:59.039 as a text format to the Internet Engineering Task Force 00:16:59.040 --> 00:17:06.319 as a new text format. So that would be quite nice. NOTE Mailing list management 00:17:06.320 --> 00:17:09.639 The Org project itself has a layer on top 00:17:09.640 --> 00:17:13.679 of the mailing list called Woof developed by Bastien, 00:17:13.680 --> 00:17:16.119 and that's about to have another major release. 00:17:16.120 --> 00:17:21.359 So what this is going to do is improve the ease of which 00:17:21.360 --> 00:17:23.319 we can actually monitor what's going on 00:17:23.320 --> 00:17:27.079 with the mailing list. So this is when people have patches, 00:17:27.080 --> 00:17:29.599 bug reports, or other types of things 00:17:29.600 --> 00:17:30.519 raised on the mailing list. 00:17:30.520 --> 00:17:34.039 It's a nice way to collect the status of those 00:17:34.040 --> 00:17:35.039 and put them all in one place. 00:17:35.040 --> 00:17:37.879 So improvements to this improve the ease of which 00:17:37.880 --> 00:17:40.399 the Org mode project can be managed, 00:17:40.400 --> 00:17:41.919 which is always quite nice to see. NOTE Further engraving 00:17:41.920 --> 00:17:46.319 There's also been--jumping back to the export 00:17:46.320 --> 00:17:48.359 which is mentioned right at the start of this presentation-- 00:17:48.360 --> 00:17:51.839 we've got the introduction of engraved faces 00:17:51.840 --> 00:17:54.479 to LaTeX export. Now what's quite interesting about this 00:17:54.480 --> 00:17:57.599 is that it's actually used as Emacs' native font lock 00:17:57.600 --> 00:18:01.239 and allows for processing that in a generalized way 00:18:01.240 --> 00:18:03.839 to different output formats. So at the moment, 00:18:03.840 --> 00:18:06.919 this is just integrated with ox-latex, 00:18:06.920 --> 00:18:11.199 but it contains the functionality needed for HTML and ASCII, 00:18:11.200 --> 00:18:13.719 and it could also be extended to other formats like ODT. 00:18:13.720 --> 00:18:18.279 So we could potentially have full syntax highlighting 00:18:18.280 --> 00:18:20.959 based on Emacs exported to, well, 00:18:20.960 --> 00:18:24.199 really all of the Org mode backends, 00:18:24.200 --> 00:18:27.359 except, I suppose, the plain text ones like Markdown. 00:18:27.360 --> 00:18:29.759 And I think from both the capabilities perspective-- 00:18:29.760 --> 00:18:33.039 because I think, really, font lock in Emacs 00:18:33.040 --> 00:18:34.199 from Emacs major modes 00:18:34.200 --> 00:18:37.159 tends to blow basically everything else vaguely used 00:18:37.160 --> 00:18:39.239 out of the water, whether it be listings, minted 00:18:39.240 --> 00:18:44.999 or other efforts--and also from a consistency point of view, 00:18:45.000 --> 00:18:49.719 this could be quite a nice development. 00:18:49.720 --> 00:18:51.119 Alrighty. Now this talk is "This Year in Org," 00:18:51.120 --> 00:18:52.599 and I think you all may have guessed 00:18:52.600 --> 00:18:57.759 this is very much tied into my work with This Month in Org 00:18:57.760 --> 00:19:00.119 which started, I think, a bit over a year ago. 00:19:00.120 --> 00:19:04.919 And so, as you're all avid readers, 00:19:04.920 --> 00:19:05.919 I'm sure you've noticed 00:19:05.920 --> 00:19:08.519 that there haven't been as many posts as of late. 00:19:08.520 --> 00:19:11.879 Now this isn't because my interest in This Month in Org 00:19:11.880 --> 00:19:15.879 has been diminishing. Simply, it's the consequence 00:19:15.880 --> 00:19:18.759 of an evaporation of my free time. 00:19:18.760 --> 00:19:22.359 However, This Month in Org is still going to stick around. 00:19:22.360 --> 00:19:26.159 The only change really is that the title is going to be-- 00:19:26.160 --> 00:19:27.999 probably continue to be 00:19:28.000 --> 00:19:30.039 a bit more aspirational than descriptive 00:19:30.040 --> 00:19:32.959 in the near future. We'll see how this goes. 00:19:32.960 --> 00:19:36.719 Well, thanks for listening to this overview 00:19:36.720 --> 00:19:38.599 of the state of Org at the moment, 00:19:38.600 --> 00:19:51.880 and hopefully, I'll see you next year.