From 7f0f4c921e6747a75802354a54e15d035b1f6086 Mon Sep 17 00:00:00 2001
From: Sacha Chua <sacha@sachachua.com>
Date: Sun, 4 Dec 2022 09:35:19 -0500
Subject: Automated commit

---
 ...22-orgyear--this-year-in-org--timothy--main.vtt | 1220 ++++++++++++++++++++
 1 file changed, 1220 insertions(+)
 create mode 100644 2022/captions/emacsconf-2022-orgyear--this-year-in-org--timothy--main.vtt

(limited to '2022/captions/emacsconf-2022-orgyear--this-year-in-org--timothy--main.vtt')

diff --git a/2022/captions/emacsconf-2022-orgyear--this-year-in-org--timothy--main.vtt b/2022/captions/emacsconf-2022-orgyear--this-year-in-org--timothy--main.vtt
new file mode 100644
index 00000000..32e3022e
--- /dev/null
+++ b/2022/captions/emacsconf-2022-orgyear--this-year-in-org--timothy--main.vtt
@@ -0,0 +1,1220 @@
+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.
-- 
cgit v1.2.3