Back to the talks Previous by track: Managing writing project metadata with org-mode Next by track: Colour your Emacs with ease Track: General

The Future of Org

Ihor Radchenko

Format: 40-min talk ; Q&A: BigBlueButton conference room
Status: TO_CAPTION_QA

Talk

00:00.000 Introduction
01:14.280 Message from Bastien Guerry
03:15.920 My step-by-step journey to Org maintenance
05:09.241 Priorities for Org maintenance
08:11.767 Modular Org
08:41.590 Slim down large Org libraries
10:00.000 Upstream generic Org libraries
11:25.400 Use modern Emacs APIs and libraries
13:13.257 Improve Org parser APIs
14:45.731 Improve Org babel APIs
15:57.380 Beyond Org code and Emacs: third-party packages, apps, parsers
16:31.200 org-contrib
17:37.820 Org orphanage
18:25.840 Mobile apps and parsers
20:23.869 Long-standing syntax problems
21:56.240 New syntax features
23:30.503 New features I hope to see in Org
25:54.073 Org community
26:01.358 Org community forums - Org mailing list
27:17.160 Org mailing list - world
30:05.580 Contribute ideas!
31:01.520 How much can a single person do?
31:35.000 Contribute code!
33:02.080 Why contribute?
35:40.240 Benefits for code contributors
37:41.420 Contributing as non-programmer
38:30.440 Got no free time, but still want to help?
39:12.997 Thank you
Duration: 39:35 minutes

Q&A

01:42.686 Q: Is the track-changes item about the org-element parser?
02:52.665 Q: Could you please keep IRC alive? I prefer it to Matrix
04:07.988 Q: Is there any plan for adding support for other modalities of notes like handwritten,  audio, etc.?
08:11.440 Q: WRT IETF standardization, have you looked at Karl Voit's OrgDown?
09:18.960 Q: About a year ago we discussed switching GNU documentation from texinfo to org. Do you still consider this?
12:26.800 Community
25:28.520 Off-stream Q&A
26:08.840 microemacs
29:31.920 Q: Is there/could there be a resource with which to recommend particularly well written codebases for review by others?
Listen to just the audio:
Duration: 30:39 minutes

Description

Discussion

Questions and answers

  • Q:<_viz> Q: Is the track-changes item about the org-element parser? [10:34]
    • A:Yes
    • <Ihor> Moreover, track-changes has been developed with my input specifically aimed to make sure that it can support org-element use case. See https://debbugs.gnu.org/cgi /bugreport.cgi?bug=70077
  • Q: Could you please keep IRC alive? I prefer it to Matrix. Thx.
    • A: I am mostly live on IRC from mobile (via Revolution IRC) and should be able to see most of the messages. Except when my mobile phone does not have good internet connection or is discharged
    • I got a suggestion to use chat.sr.ht as a bouncer. I will look into it to make the connection more reliable. (It is not bad now, but I do miss messages once in a while).

  • Q: Is there any plan for adding support for other modalities of notes like handwritten,  audio, etc.? Would that be interesting to the community? It will definitely be useful for me.

    • A: Might want to look into jkitchin's repos (possibly via tesseract)

    • You can use attachment and images to paste.

    • <Ihor> In terms of actually adding support for hadwritten notes/audio, it is not 100% clear what that support would consitute. Tooling to convert images/sound to text would probably not be appropriate for Org mode. It would be better done as a separate package(s). Then, using such tooling could be supported, but again, it is not clear what such a support would constitute.

    • "Would that be interesting to the community?" Go and ask ;) Just write about your idea in details to the mailing list and you will get feedback. What I can tell is that this topic does not surface frequently as far as I am aware.

  • Q: I spent some time writing a library for myself which involved working with org files. One thing I struggled with was finding a good source of reference code which demonstrated idiomatic usage. Is there/could there be a resource with which to recommend particularly well written codebases for review by others?

  • Q: WRT IETF standardization, have you looked at Karl Voit's OrgDown? 

    • A: Lot of pushback to this idea on the mailing-list.
      • A large part of it was about naming
      • Some links:
      • Despite pushback, Karl's idea did align with our IETF idea and with one of the point I make in the presentation about making life easier for non-Emacs apps.
        • See https://list.orgmode.org/orgmode/2022-10-17T22-36-38@devnull.Karl-Voit.at/
          • I will quote Bastien here:
          • https://list.orgmode.org/orgmode/87fsfl7g01.fsf@bzg.fr/
          • What occurred to me while rereading this thread is that definining a
          • syntax for a IETF RFC on an Org mimetype probably needs to be done not
          • just by this Emacs Org-mode community, but by bringing together other
          • "consumers" of .org files, from ecosystems outside of Emacs.
          • Such a collective work could lead to define what subset of the Org
          • syntax is useful as the corner-stone for .org files everywhere - which
          • is what you rightfully brought up with "Orgdown".
          • If successful, such a process could end up in defining the minimal and
          • official "Org syntax" while allowing implementations (like the one for
          • Emacs org-mode) to supercharge this syntax if deemed useful.
          • Perhaps TEC is right and we will end up having the minimal syntax
          • being the one we currently use for Org-mode: we'll see.
  • Q: About a year ago we discussed switching GNU documentation from texinfo to org. Do you still consider this?
    • A: We don't want to complicate org syntax to adjust to the texinfo markup.
    • ...But we want to keep org's syntax generic so that it can be customized to support the necessary Texinfo constructs

Notes

  • Nice to see mobile apps actively being considered when talking about org :D
  • Transient integration in org will be a very welcome improvement! Being able to save the transient state on org-export would be very nice indeed
  • fun fact: Transient did take some inspiration from Org's menus
    • tarsius: Oh, I did not know this!
    • From which menus exactly, those implemented by Nicolas for the exporter?
    • Not any specific menus but the "dim unreachable commands, when the user typed an incomplete key sequence" feature.
  • love to hear how folks in emacs real approach project development as social endeavors to a significant degree
  • Another mobile app that understands org-markdown is ZettelNotes (https://znotes.thedoc.eu.org/)
    • It is not the only one missed. For a reason. I did not find source code.
      • Ah ok, that is fair.
  • <jaafar>There is a Ruby parser too, in the Guthub renderer
  • As an org user but someone who is not familiar with development (and has no context on org's direction before Ihor's stewardship), I'm really excited about the priorities being expressed in this talk :) Thanks [10:47]
  • another great (and absolute core to me) app with org-mode support (respectively org files are at the core of it) for iOS devices is: beorg https://www.beorgapp.com/
    • the dev is responsive and open for feedback/feature requests, from my experience so far. i'm still "a noob", but org-mode, emacs and beorg allow me to structure my workflows/needs and to get rid of possibly many other apps/software.
    • The list of iOS-native apps are still quite small with varying quality. So far, I'm quite happy with beorg. Tried out other too (1-2 i may be missing, maybe considering buying them, even if it's just a small contribution to Emacs/orgmode as community as such). as far as the libre aspect. true, but i have to be pragmatic at some point, and firstly i want to be productive/efficient/effective. As long as it's a sole dev / community-inspired thing, and not a big corporate raider, i'm fine with non-libre software, if the standards are kept and no proprietary overhead stuff is modifying the core of org-mode (in this example for example).
  • Really encouraging stuff, thanks :D
  • Thank you yantar92` 
  • Thank you for this wonderful talk!
  • We appreciate all the work being done
  • really enjoying this talk as a long time user who hasn't ever really thought about how org mode gets developed (much less contributed)
  • For audio transcription, I use Speech Note (offline) and copy the text to orgmode
  • It's great to see Carsten, Bastien and Ihor together. I run my life with orgmode, so we owe you guys a lot :)
  • I think a huge part of Org Mode is workflow, and that's both highly individual and highly social - we learn about what's possible by hearing about how other people do things
  • Thank you for taking over org! I use it every day and I'm happy to see that org's future is in good hands.
  • YouTube comments:
    • Congratulations! I'm super excited for the things to come, especially about mobile apps not being an afterthought anymore. Also looking forward to the transition to transient menus!
    • That was a great talk. Thank you for bringing all that information together and thank you for your work on org-mode. I use it every day and it's good to see it's still in active and constructive development. I particularly like the focus on the standard and parsers to define the format and clean up code bases both in org-mode and beyond.
    • As someone who has just started using org mode, it's really reassuring to see that someone with such a well thought through, comprehensive, specific, detailed, and balanced vision of the future of org is taking the helm! May your bugs always be shallow and your users grateful <3
    • I've been using org-mode for over a decade now, and can't imagine life without it. So welcome aboard, Ihor, may org-mode continue to prosper with you as Maintainer!

Transcript

[00:00:00.000] Introduction
Hello, everyone. My name is Ihor Radchenko, and I'm the new official Org Mode maintainer. Today, I'll briefly introduce myself and then share my ideas about the future of Org Mode development. I will start by passing the word from Bastien, the previous maintainer. Then I will tell you a little bit about my story, starting from ordinary Org Mode user all the way to the maintainer. Then I will detail the new directions of development and specific features which I want to see in Org Mode in the coming years. And I will conclude by asking you, Org Mode users, to contribute to Org Mode because all the features which are too many can only be implemented with the help of the community, with the help of more contributors. And for that, of course, I will also talk about Org community and how I see it evolve so that we have a good communication between the development of Org Mode and the community ideas. Let me first pass the word to Bastien.
[00:01:14.280] Message from Bastien Guerry
Hello, everyone. Ihor Radchenko is the new Org Mode maintainer. He's been acting as such for a couple of years now, and I'm really glad he's finally agreed to take on the role officially. As a maintainer, I've probably done a few things right and certainly made many mistakes. Here are 4 lessons I've learned in 14 years. The first is that maintaining Org Mode isn't just about code, it's mostly about users. Of course, some of them will never learn how to report a bug, some of them will behave like spoiled children, and most of them will expect you to work for free forever. Nevertheless, the time is as valuable as yours. Whatever they request, there is always something that can lead to a positive outcome for Org Mode or its community. The second lesson is that maintenance isn't just about technical choices. It's also about predictability. Be very clear and very loud about what users and contributors can expect of your time, skills, and motivations. Stick to the robustness principle by being liberal in what you accept and strict in what you produce. Thirdly, it's all about learning. Let's build a culture together where it's okay to ask stupid questions. No one is born knowing how to write in English, how to report a bug, or how to maintain a large piece of code. Remember that old-timers were newbies and that newbies could become maintainers. We all have a lot to learn, even if it's just how to respect each other. Finally, as a maintainer, think about the next one. Who will be in your shoes next? What kind of maintainer do you want for a software you will be using for decades? It's also a responsibility of the Org Mode community. How can we collectively attract maintainers that want to help us use and enhance this wonderful little tool? How can we, as Org Mode users, help Ihor pave the way for the next maintainers? Enough said. I'm confident Org Mode is in good hands and I'm a very happy user. Thanks everyone for all these years of fun and learning.
[00:03:15.920] My step-by-step journey to Org maintenance
Now back to my talk. Let me start by briefly introducing myself. I'm actually not a programmer. By training, I'm a material scientist. and I only started using Emacs and Org Mode and naturally doing programming (because that's Emacs) when I was doing my PhD and I wanted to use Org Mode to tame my research work. A couple of years I was just an ordinary user, until I learned enough and got enough courage to report my first bug. Then it all evolved over the years. I started participating in the mailing list, I started learning more about Elisp, I reported more complex bugs, I eventually got around to go and fix the tricky bugs. Then I started participating more in Org mailing list in helping fixing bugs in selected areas of Org mode and eventually switching to all parts of Org. At some point I ended up doing the de facto maintenance job together with Bastien and got an actual maintenance offer which I accepted recently. The key takeaway I want you to get from here is that you don't have to be a programmer, you don't have to know Elisp to contribute, and you don't even have to be like that to become a maintainer. All it takes is slow, methodical, persistent learning over the years, participating in the community, and eventually submitting your patches upstream. And eventually you can become a maintainer, or not a maintainer as you wish. Enough about me.
[00:05:09.241] Priorities for Org maintenance
Let's talk about what I think should happen with Org Mode and what my goals on Org Mode is. The first and top priority for me is the basics. The basics, the code-based stability. Basically, all the foundations, all the APIs in Org Mode, all the basic libraries, which everything builds upon so that we have fewer bugs and we have more understandable code so that others who want to contribute have easier time understanding what is going on in the code base and contribute without much of a problem or confusion. Second equally important direction is the Org community, because a single person, even a couple of people, cannot really develop such a big project as Org Mode. And we always want new contributors, which are not coming from nowhere. We need to have the community of users. We have a community of people who participate in discussions, who later submit patches and code, and that's where we get most of the new features. So I would like to improve the communication between Org community and the development. The third direction I want to pursue is making life easier for third-party packages. Because we don't only have org-mode as it's distributed with Emacs. We have a lot of ELPA packages. We have a lot of MELPA packages. People who want some specific features on top of org-mode do develop these packages which are widely used or not so widely used. It's not only about Emacs. We have a lot of mobile apps that can work with Org files, have a lot of parsers which enable this mobile apps, or in general, programs outside Elisp to understand Org files. Fourth direction is the Org markup as a foundation of org-mode as a major mode, because we have a lot of functionality in org-mode itself inside Emacs, but it's all based on the underlying markup, and markup should have enough features to support the functions we want to see there. Last direction, which is somewhat less important, mostly because I don't have that much time to focus on everything, is the new features. I do want to see certain important features in Org mode, but I usually cannot spend too much time on them because of the previous more important parts. I do rely on the org community and the contributors to implement these new features. My idea is that I want to direct which features and how they should be implemented, but the actual people who implement them should come from the community. Now let's go into the details.
[00:08:11.767] Modular Org
The code base. As a bit of motivation, I would like to share this email from Richard Stallman, who a couple of years ago asked about improving Org mode by making it more modular. That's directly asking about improving the foundations of the code. That's what I think is an important direction as well. Here's an example.
[00:08:41.590] Slim down large Org libraries
We have a lot of really, really large org libraries, like org.el, which is like one megabyte or something large, org-agenda, org-table, org-list, a number of files which are really, really, really large. What is worse is they are hard to understand sometimes. I even have an example, alphapapa complained that part of his motivation to write org-ql and specifically his agenda part, agenda-like part, was because org-agenda is so hard to understand that it's easier to start from scratch. I don't want such situations to happen in future, if possible at all. One of the projects I'm currently working on, it's work in progress now, is splitting Org libraries into smaller parts, into more documented parts, into the APIs which are actually documented and explained in the code at least, so that people who just open org-mode code cannot be scared away and go and read the comments and understand what is happening there easier. At this point, I have almost doubled the number of libraries. It's still work in progress, so there's a lot of room for improvement in this area.
[00:10:00.000] Upstream generic Org libraries
Another direction which is somewhat reasonable in relation to splitting things down is that some libraries are really generic in Org Mode, because Org Mode often has a functionality which is really new, and for that, it had to implement some very generic functionality that doesn't have to be used just for Org Mode. This can be generalized for Emacs in general. There is a number of libraries which we may or may not upstream to Emacs, depending on what Emacs maintain, I think. As one example is org-capture, because it's a very obvious example. org-capture started as support from remember.el, which is still a part of Emacs. It has more features than remember.el, which we required for Org. But, you know, these features can be backported. Why not? And then not only Org-mode, but other Emacs libraries can benefit from these features we have in Org-mode only. Similarly, I have a long list of different libraries that can be shared. Yeah, for some I'm not sure, but in general, there is a lot of work that may be done and may be discussed in the future.
[00:11:25.400] Use modern Emacs APIs and libraries
The third part about the basics is making use of the new Emacs libraries. Org Mode in general is quite well written in terms of Emacs integration. We do support many of the Emacs features and libraries which are generic. However, in more recent Emacs versions, we started getting some new features, and we do want to make use of them in Org. For example, recently we contributed yank-media support for clipboard pasting and drag and drop. Now it is supported in Org mode already in the released version. Eventually we want to support transient.el, because now Org uses ad hoc system. It's of course much better to use existing and more powerful menus, which are implemented in transient. It even has some initial work-in-progress implementation. I hope it can be eventually extended to the whole Org Mode There are other things like compatibility, which there is an excellent Emacs library, compat.el, that provides backwards compatibility and Org also has something like this in org-compat. We don't have to write it ourself again. We can make use of the existing library. Similarly, there's a very, very new library track-changes for tracking changes in real time. Eventually, if you want to support context-menu mode, maybe touchscreen, Android support, I don't know, but I hope it can be done by someone. And some more generic library: select thingatpt. That's about using external APIs.
[00:13:13.257] Improve Org parser APIs
Now about the internal Org APIs. One important, probably one of the most important parts of Org is the parser, how Org itself understands the Org files. The situation is that we have two parsers in Org mode. One is the Org element, the proper parser, which we use as a reference, but many parts of Org still use regular expressions, which are approximate. These two parsers are not exactly consistent, which is really bad, and I hope to solve this. I already started doing some work by factoring out some part of abstract syntax tree and working on real-time parser, incremental parser, which is enabled by default in Org 9.6, but there are still parts which I need to work on. Eventually I want to get rid of regular expression-based parser completely, so that we don't have any inconsistencies inside Org Mode. One of the examples of these parts that are still using regular expression is fontification, which is often simply wrong, especially in some edge cases, and we really want to use the proper parser in this area. Maybe even editing org files using the parser syntax tree, but that might be tricky, although there is an existing library that implements some ideas for this. The key point is that org-element-api, the parser, should eventually be used everywhere so that everything is consistent.
[00:14:45.731] Improve Org babel APIs
The second important API is the Org babel. Currently, Org babel does have some API, but first, it's not well documented. Second, it's sometimes awkwardly designed, especially compared with the exporter. I do want Org Babel APIs to be more consistent. Another thing about Org Babel, it's not exactly API, but you know that documentation for most of the Babel backends are not even in the Org manual, even though the backends are built-in. They are on Org Wiki, and we do want to move them to the manual eventually. That's the important part, and it should be done. Those are some obstacles, like not all the features are properly implemented, and that's a bit of an extra job that should be done. Another small thing which thanks to Bruno Barbier is being done, in progress: we should have a more robust asynchronous API for babel. I hope it can progress further. For now, it already progressed quite far.
[00:15:57.380] Beyond Org code and Emacs: third-party packages, apps, parsers
That's all about the basics, the underlying backbone of the Org codebase. Let's move to the second important direction which is the third-party packages and basically the parsers for mobile apps. I will postpone the community to the end because I want to have a call for contribution at the end. For third-party packages, I would like to remind you that
[00:16:31.200] org-contrib
Org mode used to have something called org-contrib as a part of Org mode, which is a collection of small libraries, small packages that didn't have a proper copyright assignment basically, but more or less a part of Org mode. This is no longer the case. Now what we did is we moved a number of very rarely used libraries from Org core itself to org-contrib, and now we treat org-contrib as basically the libraries that we really want someone to take responsibility for. We want to maintain this for everything that is in org-contrib, and from me and other Org team, we do not spend too much time maintaining this package, just do some most basic bug fixing, and that's all. If you know, if you see some libraries from org-contrib and you use them, and you know Elisp, please volunteer to be the maintainer, because otherwise there will be not much progress in these libraries.
[00:17:37.820] Org orphanage
As a natural extension of this and inspired by Tarsius's Emacs Orphanage idea, we also maintain a small page basically listing the libraries, some others like packages, Emacs packages that are not really maintained. If you are a maintainer of a library and you don't have time to do it, you can write to Org mailing list and we can add the library to this page so that we can search for new maintainers in a more centralized way. If you are an Elisp hacker and you want to help something for Org Mode, you can check that page and see where you can help.
[00:18:25.840] Mobile apps and parsers
Now away from Emacs, or mobile apps. We have quite a lot of mobile apps at this point. Unfortunately, it's very hard for me and many other Elisp contributors to contribute to these apps because they are not using Elisp naturally. But these applications heavily rely on Org markup. I do hope that we can keep Org markup consistent enough and rich enough so that people don't have to invent extensions to Org like what happened to Markdown. I really want to emphasize that I want to see more Org parsers in different languages so that they can be used by developers. For people who are writing these parsers, I want to share this link. It is the org-syntax reference. It is the official Org syntax, which is what we think it should be. It's described in plain human language. It's not a code. All details should be listed there. Please use it as a reference if you are writing a parser. Eventually, this document will be submitted to IETF, I hope. In the future I hope to write a set of tests which will work as benchmarks. basically we have some existing tests for our internal parser and I want to factor out these tests so they can be used by any parser, so that we can compare the performance and which parts of Org mode are parsed and which parts are not. I mentioned that we want to submit to IETF, which means that Org markup will become the actual registered format.
[00:20:23.869] Long-standing syntax problems
But before we do that and thus fix Org markup in stone, because it's very hard to change things in the IETF, it's important to address important problems, existing problems with Org syntax. There are some problems, like I mentioned the inconsistencies between the two existing parsers in Org mode. There are also some parts, there are some examples, like there are problems with numeric priorities, for example, which are not treated consistently. There are problems, more general problems with syntax when people request some edge cases which should be addressed. Like, it's very hard to do interword markup. We have zero-width space workaround, but many people dislike it, so maybe we want to do something about it. We have some edge cases when we combine emphasis with links. We have some edge cases when we have double blank lines inside some source blocks, for example, and combination in the list. I hope we can somehow address it. It's not impossible to do it, it just requires time. One annoying part is the inline task syntax. It's annoying both from the programming perspective, internally as implementation, and from the UI perspective, because there are too many stars. We probably should redesign it eventually, maybe in backwards-compatible way, but we will see how it goes.
[00:21:56.240] New syntax features
Another part is not just fixing the edge cases or problems, it's the completely new syntax features. That's probably done after we submit to IETF. But there are important things that people often request, like time zone support in timestamps. Better repeaters, like more flexible repeaters, that's really a frequent request also. Another idea is some custom markup, which is coming to various requests, like, for example, people often ask to highlight some words with a color, for example, or with some other special way and then export it in a special way, just as we do with special blocks, basically. What I want to introduce is the ability to do it on a macro level or inline. Of course, a new syntax feature which I wish we could have is the multi-line cells in tables. It's very frequently requested as well, but I really have no clue how to do it. We had a discussion about this in previous discussions, but there was no conclusion. We don't see a good way how to implement it syntax-wise. Unlike time zones where we decided exactly the syntax, how it could be and we just need patches to be submitted, here even the idea of syntax is not clear. Please do participate in these discussions if you have ideas.
[00:23:30.503] New features I hope to see in Org
The last direction is the new features. In general, I welcome all kinds of good features, but there are certain things which I explicitly want to see and I hope to see submitted. If you are interested, please do submit patches. One, and probably many people are aware about it, is the asynchronous LaTeX preview, developed by Timothy and Karthik. I hope it can be finalized eventually and upstreamed. It's pretty much in ready state, but on the technical level it should be discussed further and revised. The second is org-ql by Adam. I hope it can be upstreamed. It's also a work in progress. It's just a question of free time for Adam mostly, I think, and me. That's another important part, new feature. The third is the so-called multi-page export. The idea is the same as many packages for blog posts, so that you have a single Org file and then you can export multiple HTML pages, for example, or PDF pages, anything like that. This work in progress by Orm, thanks to him, although it was a little bit stuck because I am not exactly sure how to best integrate it into the existing APIs. If you are a developer of one of the blogging packages, I would appreciate if you can chime in and probably share some ideas here. Next are just some wishes I wish we could have, but it's not very detailed. One is the multi-language support, so that we can have Org documents in multiple languages, or maybe even translations. The collaborative editing that many people would wish to have, I think. Things like tracking changes, adding comments, importing from some other Org formats with the comments and changes so that we can actually participate with all those Microsoft Word users and stuff like that. But that's really too much for me alone to handle. If you want to see one of these features, please consider contributing. Just write the mailing list about your interest and we can start from there.
[00:25:54.073] Org community
Now, the important part is, you see, I keep asking people like, please contribute, please contribute, but who should contribute?
[00:26:01.358] Org community forums - Org mailing list
So I want to improve communication between the community and the mailing list. Now, people often discuss new features or ideas on all kinds of places like Reddit, Mastodon, like all kinds of Matrix/IRC chats, even on meetups, some non-English language. That's very nice that we have this community, but not all the ideas are visible to the developers. I do wish that the most important things that people want to see should end up on the mailing list, one way or another. I'll later talk about some ideas how I think it can be done. Another part is we have org-wiki and I hope that we can make it more centralized space for interesting Org mode articles, for tutorials, for blog posts, at least linked to blog posts. If you have some idea about good blog posts, it would be nice if you submit a patch to work or at least email about this link to the mailing list.
[00:27:17.160] Org mailing list - world
Of course, not everyone likes to use mailing lists or don't have a good setup to do it, or even don't want to read everything on Org mailing list, because there are things like bug reports, people don't really want to see that. So Bastien actually developed a tool that can help with this. If you want to monitor Org mailing list, but want to see only the most important discussions, and maybe participate if you decide to, you don't have to register. We have Woof, which is basically a web page that monitors our main list, but not every email. That's the most important announcements, some blog-like posts, or feature requests, or some discussions. Then on this webpage, you can see it as HTML, or you can subscribe as RSS, or even download in Org or MD format. Thanks to Sacha Chua, also weekly news about Emacs in general, but Org Mode as well. It also includes the new features in Org Mode on the development branch and the interesting new blog posts and discussions on various Reddit forums or mailing lists everywhere. I did this little bit of experimental integration so that many lists can also be read, kind of announced on the chats. For example, in #org-mode Matrix room, we have a bot that connects to Woof RSS so that all the news and discussions are notified in the chat so that people can see if they are interested and maybe, hopefully, participate. I wish we could also have similar kind of both for Reddit, Mastodon and maybe IRC. That way we have mailing list connected to more active and more modern forums and chats. More people exposed to what is happening. Another part is that we actually have a web interface to Org mailing list and you can even reply from there, but it's not always obvious, unfortunately. We have this public inbox software to transform the mailing list into HTML pages. That's a decent interface, but it could be improved to look more forum-like, so that people can easily find the reply button or basically participate without too much effort, even if they are not subscribed or they are just casually reading. That would be nice if someone knowledgeable of CSS could help with this.
[00:30:05.580] Contribute ideas!
Again, I cannot emphasize more that most of the Org ideas of the new features are coming from people, but often they are known either by someone submitting a patch to the mailing list or submitting an idea to the mailing list. Rarely, it happens when someone is reading posts from Reddit that don't share to the mailing list. If you think that there is some important discussion happening on the forum, it would be nice that you can go ahead and share it with Org mailing list. We don't care about on-topic, off-topic, because unlike emacs-devel, we don't focus on development. We can discuss some related to Org mode topics in open-end list, just like on an ordinary forum.
[00:31:01.520] How much can a single person do?
I would like to end my talk with the call for contributions. Let me explain a little bit, because you saw now I shared many many ideas and I do spend a lot of time on Org Mode. In fact, for the last year, I was spending like 30 hours per week or something. Until recently, I can spend a bit less, but still even with that much of commitment, there is no way I can handle everything by myself.
[00:31:35.000] Contribute code!
We really, really need more people to contribute so that Org mode keeps moving forward. Again, I just shared ideas, but I have so many more. I have more than a thousand ideas noted down. Yeah, there's no way I can do it myself. I do need help for new contributions, for new features. If someone can help fixing bugs, it would be really great. If someone knows specialized things, like for example Open Document Format, which I don't know very well, it would be really nice, because things like ODT export requires knowing that, and if someone already has the knowledge, it would be much easier if that person can help with such things. Although in the coming years, it's very important to have regular contributors because my life is my life and things may happen, so it would be nice to have some kind of backup so that bugs keep being fixed and things like patches being accepted and stuff like that, so that some person can at least temporarily take on my job. I would like to emphasize that the code contributors are the most important contributions for Org Mode. All other types are less important, really.
[00:33:02.080] Why contribute?
I want to spend a couple of slides trying to motivate you to contribute. If you ever considered contributing or if you ever wished to have some feature in Org Mode, really don't wait, because most new features are contributed by people. They are not contributed by me. I contribute a few things, but I am alone. I cannot contribute many things. Most of the things are contributed by users who go ahead and submit patches. And even in very commonly requested features, it's usually someone who steps up. If you want something, don't wait. Just go ahead and write to mailing list. You don't have to submit a patch immediately. You can just say, I am interested. We will start from there. We'll start because that's my job and I will guide you through. If you have problems with Org in general, I'll explain, because that's what I know. I will explain how to implement things better, but I need someone to actually do the job and write the code. Even if you don't have 10 years experience with Elisp, it doesn't matter. You can learn on the way. There are many examples of this in the mailing list when we start slowly, fix things one by one, and eventually arrive to a good quality when the person is not experienced. You just need to be ready to learn things, Spend your free time (that's as usual, right?), and have the interest in specific thing you are contributing. Don't be afraid to be wrong. I will be there to assist. If you don't like emails, if you don't like patches, it doesn't matter. Again, you can share GitHub link. It's okay. You can go and modify some workflow directly. You submit the modified version. It's also okay. It's easy for me to create patches if I need to. If you don't like emails at all, you don't want to participate in the mailing list, it's not ideal, but I can still work with this. I am on IRC, I am on Matrix, you can ping me, it's yantar92. We also have monthly meetup, so you can go and ask by voice, we can just talk in person, discuss your ideas, it's also fine. The key point is that we always welcome new contributors. The more contributions to Org Mode is better.
[00:35:40.240] Benefits for code contributors
To increase the motivation, I'll just try to show some benefits of contributing to Org Mode and free software in general. It can be actually useful for your CV if you're a programmer. It doesn't matter if it's Lisp, because you can have a pet project that demonstrates your skills, that you can finish something to a usable state. A pet project usually demonstrates that you can work alone, but it doesn't demonstrate anything about you working in a team, in the production team. When you contribute to Libre software, look, you will work with a number of people who contribute and comment on your work. You'll have to learn a new code base. You will have to follow certain standards. All these things, by having a public record of contribution, will be a valid point that proves your knowledge in your CV. I put a small quote (which I'm not going to read in the interest of time) from Rudolf Adamkovič, who is describing these three points in probably a more expressive way. Another benefit is you can actually get money from this. Thanks to a number of Org Mode users who kindly contribute to Org development, we have some amount of money coming in, and we don't hold on this money. If we get another person who contributes to Org regularly, we are happy to share this money, because we do know that getting some extra money, even a little bit, does improve motivation. We are really ready to share this. If you are serious about contributing, you can just request this and we can share a part of the donations to you.
[00:37:41.420] Contributing as non-programmer
For non-programmers, we also have a lot of work to do. There's a lot of stuff we can do on the Org wiki, especially with CSS styles, with updating articles, with adding links to tutorials, or even writing tutorials about Org Mode. It would be nice to have more screencasts. It would be nice to improve Org manual, because that's the most difficult part for me because I'm too familiar with the code. Writing the manual when you know things internally is very hard. I just know too many things. I can assume that people know too much, that new users have no idea about certain things. I can just omit those without being aware.
[00:38:30.440] Got no free time, but still want to help?
The final slide I would go to come back is about donations. Again, most important is contributing code, but I do hope that donations can increase the number of contributors. I don't know. I know for sure because some people like Timothy, who is participating in this, he did find the donations helpful, especially for more boring tasks like bug fixing and to move things over the long time. If you cannot contribute by other means, it would be appreciated to contribute money.
[00:39:12.997] Thank you
We came to the end of my talk. Thank you for your attention. If you have any questions, please feel free to ask. I think we can even discuss further during the next Org Meetup in the coming week. There, if you have more detailed questions, we can continue discussing apart from what happens after this presentation.

Q&A transcript (unedited)

And I believe we are live. Okay. Hi again, Ihor. How are you doing? Ready to answer questions, right? Yes. Ready to answer questions and all this. I mean, ready for everything. It's not just a question, it's the maintenance that is now lying in front of you. So... Oh, that's not the end of the day. I mean, it's a rare thing indeed, because you might not be able to see it on BBB. I'm checking in, but we've got Ihor, obviously, but we also have Bastien and also Carsten in the room. So, we have three maintainers of Org Mode right there in the room to answer all your questions. So, it's a rare occasion that I invite all of you to seize the day on this. Ihor, do you have anything maybe to say before we start moving into the questions? Well, I hope that I said everything I wanted. Hello, Bastien. during the presentation. Well, actually, I can say a lot more, like infinitely, because when I first recorded it, it was like one hour. So yeah. I mean, you did a, I'll just let you know, you did a fine job condensing everything in just 40 minutes. So congratulations on this. Yeah, it's, yeah, usually one minute per slide is the best way. Otherwise, it's something that's wrong with this presentation. Right, so just moving into the question, and by the way we've got 20 minutes, we might be able to chat a little more if Bastien wants to say something as well and Carsten, you know, feel free to intervene at any point during the questions if you've got anything to contribute or our voice will just show the breeze later on. So the first question is relating to something you said about 10 minutes 34 that might speak more to you than to me.
[00:01:42.686] Q: Is the track-changes item about the org-element parser?
Is the track changes item about the org element parser Yes, the track changes is a new library that helps to receive changes in buffers incrementally. So like you can, it has API where you can request what changes happened in buffer since last request, chunk by chunk. And in org mode, in org element parser, we do pretty much the same thing, but using timers. So this track changes library should improve things, first, because it's a bit faster, because we don't need to conjure every single change, and track changes can agglomerate changes into chunks much more efficiently. And second, it's a built-in library, so it's a good idea to use built-in library when there is such an option, instead of running out our own implementation. Definitely. Moving on to the second question, although I'm not sure it refers that much to what you can do.
[00:02:52.665] Q: Could you please keep IRC alive? I prefer it to Matrix
Could you please keep IRC alive? And I prefer it to Matrix. I mean, you did talk about IRC, right? But did we talk about phasing it out? So I try to be live on IRC, but I use mobile client for IRC to keep connected. So I usually connected, I usually see messages, except certain times when I don't have mobile internet. Right. Okay. That's why many people will tell you, you need a bouncer and all this, but the IRC crowd is very loud. I just don't know a good bouncer. I don't have a good setup for a bouncer. Okay. Personally, I use WeChat usually to stay connected to email. It's obviously a client for IRC, but it also allows you to, you know, you can keep it as a bouncer, but it's not in Emacs. It is. I don't have a computer that is running 24 hours, so. I mean, that's the thing. I do have a server to run it off. All right, moving on to the third question. That is what is running 24 hours. Right. Okay. All right. Moving on to the third question.
[00:04:07.988] Q: Is there any plan for adding support for other modalities of notes like handwritten,  audio, etc.?
Is there any plan for adding support for other modalities of note-like, handwritten, audio, and et cetera? Would that be interesting to the community? It will definitely be useful for me. I didn't. Okay. So this is not the idea I hear frequently. So there's no plan for such thing. Modalities of notes like handwritten audio. I think John Kitchin did some handwritten note. John Kitchin. Yeah. And for audio, I think as well. I. So basically you can use attachments, you can use images to paste you. I think John Kitchin even use it to automatically recognize notes. I think the previous speaker was talking about a whisper to recognize voice. Right. Otherwise there is no special workflow and I'm not even sure what we can do to support this workflow specifically. Yeah, it definitely feels like Org Mode is a good format for textual stuff, and a lot of things are textual. I mean, that's the whole philosophy behind Emacs. But when it comes to voice, it feels like it's... I think the person asking the question probably needs to specify what they mean by voice. Is it just raw note-taking, as Blaine mentioned in a previous talk, or is it something else? Feel free to add up to the question and we'll return to it later on. I think this is kind of related to drag and drop. I think you would like to be able to have an audio file and drop it in and have it translated to text. I think that would be an interesting API to do this, right? So that you can integrate it into something like drag and drop. I think I'm going to talk with supporters in since overnight. So we have, I believe what constant is alluring to is the fact that not just pictures but imagine if you were bringing in an audio file maybe you could, I mean I'm not sure it would work with whisper but. transcribing it in a way and inserting it as text. Although I'm not sure how we would be able to do this, but it's an interesting idea though. It can work if you write some kind of automatic speech recognition. It's not really a job for work. If you have some library that can transform audio to text or transform image to text in Elixir, then we can happily use that library. Definitely, but I can tell you that Whisper is not something that works very quickly. We do use Whisper AI to transcribe some of the talks that we broadcast during EmacsConf, and I can tell you it takes a fair while. If you have a video that lasts one minute, it's definitely going to take more than one minute to try to transcribe the video. We had to wait for a few years until it passed. Probably, but it's good to have the ID now so that we are ready eventually to do this. There is the new asynchronous IP. It's called org-pending. It's work in progress. And that basically allows to defer inserting text into our buffers until later. And while it's being worked on, it will basically highlight the place where it will be inserted. And you can click on it, see the progress, and stuff like that. So this is for Babylon, but I imagine for things like voice recognition, it can also work. All right, what I suggest we do, we're going to fill the two questions that we have now, and then it'd be nice if we could hear a word from Bastien and from Carsten as well, because it's rare to have all of you three in a room, and it would be nice maybe to chat a little bit about this. So quickly, with
[00:08:11.440] Q: WRT IETF standardization, have you looked at Karl Voit's OrgDown?
the last two questions, with regards to IETF standardization, have you looked at Karl Voit's Orgdown? So, of course, there was a discussion on the mailing list, and there was a lot of pushback to this idea, especially to simplify the syntax. So, in short, the conclusion from there is we want the full syntax, we don't want to have things like different versus Org mode. But for the syntax, we may specify different like coverage. So for example, it's a minimal, it has a minimal support so people can, there's some parsers or apps can support just whatever curl calls fork down like level zero or level one or whatever. But the key point is, when it goes to IETF, we want to have the full syntax. We don't want to split it into pieces. Makes a lot of sense. All right. And the last question we have
[00:09:18.960] Q: About a year ago we discussed switching GNU documentation from texinfo to org. Do you still consider this?
for now. About a year ago, we discussed switching new documentation from texinfo to org. Do you still consider this? definitely contributed to some of the ideas about syntax. For example, the inline special blocks, I think about them with this in mind, so that, so basically, one clarity, we don't want to complicate our syntax, we don't want to have special built-in support for variable, or I don't know, function name, or all this kind of specific markup. But instead, the idea is to have some generic custom syntax. And then when it goes to software manuals, we want some like optional library that will provide certain syntax extensions, like inline special block for variables, inline special block for acronym and stuff like that. Then people who want to use Org mode for manuals should be able to use that new markup to achieve what they want. That's a distant idea. But the key point is we want to keep org mode as generic syntax. We don't want to specialize it for software specifically. But generic in the sense that it can be used for software as well. All right, well thank you so much for your answer here and that was very enlightening but I'd first like to give the mic to Bastien who might need to leave shortly and I just want to make sure that you get to chat a little bit Bastien because it's a big thing we've had you as a maintainer for however long now? Well, officially, it was 14 years. But obviously, EHO has been doing much of the groundwork as a de facto maintainer for several years now, I believe for three or four years. And before Before IHO, there was Nicolas Goaziou, who's doing a lot of work. Also Kyle Meyer, who is still active, backporting Emacs changes. So it's a relief that we can do things properly, that I didn't give up before someone could really step up. I'm glad we're doing this. And I'm glad there was so much help during the time when I was not available enough. Well, thank you, Bastien. I think on behalf of the community, I think I'd like to extend a big thank you for all the work you've done throughout those 14 years. And if we pull the rope just a little more, before those 14 years, we had someone else maintaining Org Mode, well, not actually just maintaining Org Mode, but also inventing it. Carsten, how are you doing? I am. I'm doing fine. A really great opportunity to be here.
[00:12:26.800] Community
First, I would like to start by indeed thanking Bastien because, I mean, he was not only maintainer after I stopped, but already during the time I was there, he was one of the key contributors who helped the project along for quite a bit. So it's an incredible investment of time and energy that Basquiat has shown, which is really fantastic. And now I see Ihor taking over with, as far as I can see, deep knowledge and all the right ideas about philosophy. So I'm really impressed. For me, this is really totally amazing because I started hacking this more than 20 years ago. And to just see that there's a community that has sustained itself with the help of new maintainers for such a long time makes me extremely grateful. So thank you very much to all of you. Okay, well, amazing. I mean, I'm a little flustered, I must admit, because I'm seeing three players of the community in a way that have kept me busy with very fun stuff to do with Org Mode, and it's really amazing to see three giants of the community being able to maintain Org Mode for so long and contribute so much to it. So, again, thanks to all of you three. I must also admit that it's really amazing for me that all of you three stress the importance of the community a whole lot, and I know that Bastien, you've talked about maintaining software last year at Emacs Confs, and even today, during the one-minute little chat that you did in Ihor's chat, you stressed the importance of maintenance and to be future-oriented about it. I'm kind of wondering, why do you think community is so important to Org Mode in general? Like, obviously we've talked about maintainers and we've talked about volunteers, but don't you think there's something more about community in general, about Org Mode and the fact that we are all taking notes and doing so much with it? Yeah, are you asking me? I remember Carsten made his point during the Google talk about the core idea of Org Mode, about mixing note taking and to-do manager. It was really powerful. And also in the same presentation that 98% of the features were organically developed as ideas by the community. And Ihor just said the same today in the presentation, like most of the features, not only the ideas, but also the code came from the communities. So that's why the community is so rich. And another thing is also that I do remember. Now everyone is having kind of an open source fatigue and questions about how is it okay to be maintainer? How do you keep open source project sustainable? And I'm saying open source on purpose with this audience to see beyond just the small GNU project and the small free software community. So at large, there is some sense of fatigue. I remember that the Org community right from the beginning had a reputation of being an amazing community and I think it continues to be one and I'm amazed that sometimes when I'm, you know, sometimes I'm, I have this fatigue of moderating emails from the mailing list, for example, and filtering out spam. And then I go on the list and I read some emails and I feel like, okay, this is still there. And it's really a boost of energy. I wish that this repetition outside Org Mode, outside Emacs, of being a nice welcoming, community of knowledgeable people talking of things and learning from each other that we can keep up with this pace. Yeah, maybe if I can just add to this, I think you're making an extremely important point, Pascal. I think that was really, from the beginning, something that was really special. And I think the reason why we all community still works is that first me, but in particular also the two of you and more people have been able to keep up the friendly spirit in this community. Because we had very few fights on the mailing list. There were a few at some point, we had a few contributors with a little bit of fights. And I remember that I, for example, had to invest a lot of time to keep that one under control, but I think it was totally worth it because as a group, as a whole, I think it was really fantastic. Our friendly people always were, and I think that has spurred all the contributions that we had. Because if you are in a toxic environment, you will not be willing to stay and to invest all their time. And if you are in an appreciative environment where people support each other, it's a completely different game. So I really think that Org Mode is a great example for open source projects that many other communities can learn from. If I may just interject for a second, because we need to go into the next chat for the live stream. But as usual, I invite you, if you're interested with the discussion, we are staying on BBB, asking questions to Bastien, to Ihor and to Carsten. So feel free to join on BBB and chat with them live. The stream will be moving on to the next chat, but we will be recording the Q&A and posting it afterwards on emacsconf. So, I'll use the opportunity to thank you again, all three, for taking part in this EmacsConf, and enjoy the discussion, and we'll see you later! Thank you, bye bye! So, yeah, what I was starting to say actually is I feel that the Org Mode community and to the big extent the Emacs community is a bit like research in the early days when there was a bunch of enthusiasts who just exchanged mails together and tried to find out something new. And there was like no feeling of competition or too much competition at that time. Unlike now when we like we all rise for funding and stuff. So it's, it's really, it's really nice to, to, to have communities that has the spirit and they hope it can keep the spirit in future as well. Yeah. Yeah. I thought I'm very optimistic after. So I mean, actually had not been reading the mailing list for quite a while, but I started to read it again a little while ago and I could just see you also working on it and see how everything was going. That made me extremely happy to see that and made me very proud that this is still ongoing. I was interested about your point about the tables with multi-lines. My unsolicited advice is don't do it, because I think it's going to be a mess. Which I think is reflected also by you saying that nobody has a good idea on how to do this. I have certainly thought about it. It is requested so often. It's requested so often that it feels like it would be nice to come out with something. The question is, it is what? Yeah, that's a big question. Because I don't always ask eDocs, for example, and they do have multi line cells in tables, but that syntax is so ugly. Yes. Yeah, no, exactly. I think this is a problem and the question is, how far do you want to develop or want to be a completely full authoring system in the sense that you have all these options there because I think to me, the Org Mode tables have a specific application. They have this fast way of building something. And if I would have to go and build a hugely complicated table with different numbers of columns and columns going away and appearing further down the table, so I would probably go somewhere else. So for me, this seems to be overkill. So I don't want to curb anybody's enthusiasm. But I think it's really important to keep to keep the kind of functionality that it has. It's a very easy use and quick ability to do something interesting that I think is more important. There could be reasons to not do something. So again, the thing is, we don't have a good idea. But what I know 100% is that we are not going to give up the existing syntax. Yeah, for sure. So even if you come up with something good, the existing syntax will remain working. And if people who need to use simple tables, they should remain possible in exactly the same way. But I know many people struggle and try in LaTeX and other workarounds just to create more complex tables. So there's clearly a demand. I think this is related to the other question that you asked earlier. I think it's related to the question about the different parsers. And then, of course, the way the tables are implemented now is by basically just looking at what's around you and doing the right things with this regular expression-based part of the parser. And you probably would have to fully use the other parts and to do all the changes in the formal structure in order to do something like this. So I have to be honest that I don't understand this well enough to really have a meaningful idea about it. Not only that, we'll also need to rewrite the spreadsheet functionality because it is completely using regular expressions. Exactly. Not only idea is missing that the roadmap will be very complicated if you get there. Yeah. I mean, I do remember. Yeah, go ahead. Yeah, sorry. I do remember Richard Stallman saying that Org Mode was doing too much. So my answer was just, coming from the inventor of Emacs, I took it as a compliment for Org Mode. But of course, that was just humor. And I agree that the simple things should keep being simple. And I like the custom syntax idea of Juan because it goes in the direction of flexibility while keeping things simple. And looking forward to what people will come up with. I like the idea that you want to formalize the syntax. I think that is really very good. I'd like to also submit it. I think that would be excellent. I'm also... I think it was proposed by Timothy, yeah. Initially. Okay. Yeah, that's really helpful. Pascal, are you still talking, I think? No, yeah, I just wanted to say also for the younger Emacs users, there is a lot of new things in Emacs the last five years. It has been so exciting. And I believe it's exciting for Org Mode too, the things you mentioned about track changes. uh native compilation and all that stuff that that's really good like some some performance problems that we had for org mode for the agenda and stuff like that were suddenly solved by uh the the crazy amazing work by Eli and emacs maintainers so it's really exciting for org as well. I don't know how you feel, Ihor, about this, but I know you are reading the Emacs development mailing list and keeping this is a job in itself, but it's really exciting for everyone, I guess. Not only that, I hope we can upstream org-ql, which will speed up agenda specifically even more. Okay. I need to fly away, but it was really nice connecting and I hope everyone has a great conference. Bye-bye. It was so good to see you. Thank you again for everything that you have done. Thanks to you both. Thank you. Bye-bye. Bye-bye.
[00:25:28.520] Off-stream Q&A
All right. Is it only the two of us now? I don't really know who else. Can you see if there's anybody else in this room? I don't know. There are like two, four, six people and Sacha is one of them, so probably five people. Oh, Sacha is here. Okay. I haven't heard her say anything, but I see her in the chat. Okay. It's the same room, basically. Hi, Sacha. Oh, okay. They're also at her pad, so we may want to finish other questions, maybe, if there are some. This is just a circle.
[00:26:08.840] microemacs
This is just a historical question, but Carsten, I think you used microemacs back in the day. Did that have any influence on Org? That is a really interesting question. I used microemacs as my first version of emacs, and then I stepped over to Emacs. I actually did two things at the same time. I also was working with so Awk basically, that language. I ran against walls with both Micro-Emacs and with Awk, where I had the feeling I don't have enough freedom to do everything that I wanted, so I switched to Perl on one side and to Emacs on the other side. That's what it was. Micro-Emacs absolutely had the function to pull me into Emacs, But it's not that I have specific microemacs features that would have triggered me to do something for Org Mode. I think that would be the answer to your question. All right, thanks. Are you a user of microemacs, George? I posted the source to CompSource's Amiga in 86, and I was somewhat responsible for it being in the wild. Oh, I'm so sorry that I didn't, wasn't really aware that I made the connection to your name. No, no, no, no. We all moved on and the world is a better place. Yeah. No, I actually did use it for something like, I think six years as my only admin at the time before I made the switch. No, I put it out to the list. David Lawrence ran with it and you know, that was about, that was the end of it. And I actually implemented something like fly spell for microemacs. I remember doing that at some point. Yeah, no, I don't want us to get stuck on that. I don't want us to get stuck on that, so. Yeah, yeah. Good. Thank you. Thank you for Org Mode. Yeah, you're most welcome. For microemacs, actually, I also tried it once. It feels like at home after Emacs, of course, the major downside was at this point is that there is no UTF support. I think that was like, unfortunately, that that's not going to work. I think I'm also going to disconnect now. But it was really fantastic to listen to your talk. I wish you all the best. I'm sure that is a good answer. Thank you for joining, and nice to meet you. Yeah, bye. Bye. Okay, so there are still people in the room, so if you want to ask questions, feel free to do it. I think there's one unanswered question in the etherpad also. Let me see. It's probably awkward to answer. Okay, I can answer and then probably answering the answer for this one. So there's a question about, from a person, I spent some time writing a library for myself, which involved working with Org files.
[00:29:31.920] Q: Is there/could there be a resource with which to recommend particularly well written codebases for review by others?
One thing I struggled with was finding a good source of reference code which demonstrated idiomatic usage. particularly well-written code bases for review by others? That's a good question. We have some wiki pages. I'll put it in the answer later. You can also check Org Mode's code, but usually in org-element there are good usages, and in Org export. Otherwise, maybe something from Alphapapa, but I need to check that and probably reply later. Otherwise, that's all. So I'm going to end this. Bye bye.

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

Back to the talks Previous by track: Managing writing project metadata with org-mode Next by track: Colour your Emacs with ease Track: General