[[!meta title="The use of Org mode syntax outside of GNU/Emacs"]] [[!meta copyright="Copyright © 2021 Karl Voit"]] [[!inline pages="internal(2021/info/org-outside-nav)" raw="yes"]] # The use of Org mode syntax outside of GNU/Emacs Karl Voit [[!inline pages="internal(2021/info/org-outside-schedule)" raw="yes"]] With the rising interest in Org mode, the GNU/Emacs community gained much momentum in the last decade. Being [a nicely designed lightweight markup language](https://karl-voit.at/2017/09/23/orgmode-as-markup-only/), Org mode does not only benefit users of GNU/Emacs. There are many tools and services supporting Org mode syntax documents that do have no direct connection to GNU/Emacs. I would like to elaborate on the advantages on using Org mode syntax for arbitrary text outside of GNU/Emacs for better typing usability and collaboration tasks. Unfortunately, we do face some issues with the current situation. First of all, we do already have a number of non-Emacs tools that do support Org mode syntax. Then, we also do have an unclear consensus of what it takes to "support Org mode" without re-implementing the whole feature-set of Org mode of GNU/Emacs. For that purpose, I came up with a new name for the syntax of the Org mode lightweight markup language: **Orgdown**. Please do visit the [Orgdown homepage](https://gitlab.com/publicvoit/orgdown) and read my motivation article [Orgdown - a New Lightweight Markup Standard for Text Documents](https://karl-voit.at/2021/11/27/orgdown/) for further information. # Discussion IRC nick: publicvoit - is there a tree-sitter parser for orgdown already? :P - it seems to me that as org evolves, either orgdown eventually becomes incompatible with org or org is prevented from changing because it would break orgdown. I guess backcompat with existing org documents constrains org-mode this way already, though - what level would you call github's implementation is? - i'm not sure if we want a proliferation of org-syntaxes like markdown's - Disentangling "org" the markup language and "org"/"org-mode" the piece of software that runs inside Emacs is long overdue - I gotta say, why "Orgdown" and not just "Org"? That way we've got "Org" (the markup syntax) and "Org-Mode", the mode for that. Just delineate the mode from the thing the mode handles. - there was a move in the opposite direction, using "Org" instead of "Org-mode" for the piece of software that runs inside Emacs, which to me is where the problem arises... - +1 for "org" aas the format name, and the (already present) derived handling of the format being org-mode! To be clear, +1000000% in favour of this generally. - Next year. Talk on presenting org as a mime-type. Who? - it's officially being considered as a 'thing to be done or at least talked about', but I don't have a better status than that. - I think the org/orgdown split makes sense: orgdown stripped-down org - Why GitLab? GitLab.com requires reCAPTCHA to sign up, and nonfree cloudflare js to sign in - publicvoit: I wanted to test an alternative to GitHub which I was using so far. - I recommend codeberg.org, notabug.org, sr.ht, or savannah.nongnu.org - already uses the ".org.txt" file extension, so that tools that don't otherwise support the org file type will at the very least read them - sorry to have missed out on the discussion during your talk, but I'm extremely interested in getting org working outside elisp (re: https://github.com/tgbugs/laundry/tree/next). I started there long ago, at this point the issues that really need standardization is org-babel, but in order to do that we need the syntax settled, which has turned out to be a _lot_ of work - having orgdown as a way to talk about files that have org syntax seems like it is a critical piece for effective outreach - would it be worth considering a decoupling of the "orgdown" proposal into 1) just a proposal to rename "org" the markup as "orgdown" (vs "org-mode" for the piece of software running in Emacs), and 2) all the rest as in the levels/etc? Just to not put the first at risk of non-adoption because of the contents of the second? There seems to be a lot of positive sentiment towards solving #1 for sure. - orgdown is not org, the markup - orgdown is lightweight org, it does not have all the features - In general I agree, there will be issues with how to approach the levels - publicvoit: Valid approach but this train has left the station already by the decision of myself to provide OD1 to the public this weekend. - To be fair, I personally don't think adding tiers to org-mode makes much sense - We should rather have a feature matrix for stuff like pandoc to check against - developing the test suite will get us there, and then we can have the discussion about how to market the levels - I think we could adopt orgdown almost immediately without issue - I don't really see a big issue with org-mode vs. org vs. orgWHATEVER though - there are major search and discovery issues with bare "org" - I tend to use "org syntax" at the moment, but it isn't catchy enough # Outline - The term Org mode stands for different things - The Org syntax is better than much more dominant lightweight markup languages - We do have an unclear consensus of "Org mode support" - A new name for the syntax alone: Orgdown - What Orgdown should be and should not be - Advantages of Orgdown for everybody - Orgdown comes in different levels: Orgdown1 - OD1 Compatibility Percentage - The future of Orgdown - Your contribution! # Personal information - Name pronunciation: sounds like "karl foit" ([IPA](https://en.wikipedia.org/wiki/International_Phonetic_Alphabet): [kaʁl](http://ipa-reader.xyz/?text=ka%CA%81l) [foɪt](http://ipa-reader.xyz/?text=fo%C9%AAt)) - Pronouns: he/him - Homepage: [https://Karl-Voit.at](https://Karl-Voit.at "personal web page of Karl Voit") - Preferred contact info: EmacsConf21 (ɶt) Karl-Voit.at [[!inline pages="internal(2021/captions/org-outside)" raw="yes"]] [[!inline pages="internal(2021/info/org-outside-nav)" raw="yes"]]