path: root/2022/captions/emacsconf-2022-orgyear--this-year-in-org--timothy--main.vtt

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.