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.
