1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
[[!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"]]
<!-- You can manually edit this file to update the abstract, add links, etc. --->
# 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
BBB:
- Hi Karl. I was wondering, does the specification make any restrictions with regard to indentation levels or hard vs. soft line breaks? Do you have any type of test suites that an implementation can use to be "certified" as orgdown(1)?
- Are you worried about the different levels of orgdown leading to the same confusing situation we have with Markdown?
- I think the ability to indicate that some tools are compatible with org is fantastic!
- Less of a question and more of an idea: I feel like it might be clearer to have more "semantic" names for orgdown such as "basic" orgdown, "full" orgdown or something. Those names are not great, but I think that might make it easier to remember what is what. Thoughts? Was there a specific reason for choosing a numbering system?
- I like the Idea very much. There are some Mobile Markdown/Text Editors which shy away from support for org-mode. Maybe with orgdown support will be more widespread.
- Questioner: And we should really try to proliferate the orgdown compatibily
- Was the syntax specification based on commonmark in any way?
- I think my main concern when writing in org mode at the moment is that exporters aren't heavily test (I found the plain text export was accidentally mixing spaces and tabs in indentation). Do you have any thoughts on a specification of reference implementation for an export process? Or is that out-of-scope?
- although usb 3.2 2x2 is also not much clearer
- Oh, tags are not included in orgdown1 ... would this come in 2, or is there some workaround?
- I like the Idea very much. There are some Mobile Markdown/Text Editors which shy away from support for org-mode. Maybe with orgdown support will be more widespread. I did actually plan on making an org-roam focused app, for which I will definitely include the orgdown compatibility! Very excited about this
- You already answered this (tags). Sounds good to keep it simple at first.
- On the gitlab page it mentions that GH/GL have 95% support for orgdown: what is the 5 missing percent?
- Are you hoping for most of this discussion to happen through GitLab?
- Shame that gitlab does not have a github like discussion page yet
- Did you get any feedback from the Org mode maintainers?
- Just wanna preface this that I don't wanna complain about GitLab. Just also bringing up what a few folks on #emacsconf said as well. Sourcehut could be used, especially because of its mailing lists feature. The only other reason I could see that being interesting is that the head of Sourcehut is a large Gemini advocate as well. That could motivate more attention within the growing Gemini community for using Orgdown (outside of Emacs).
- Yeah, honestly, I'm excited to see what the rest of the Org community would want. Whatever platform, I'm excited to start contributing when I can.
- There seems to be a similar simplify-the-org-format approach in this recent neovim project: <https://github.com/nvim-neorg/neorg,> FYI. Might be worth looking to see if orgdown1 is compatible
- neorg seems to be an expanded org-mode syntax and is not compatible with orgmode
BBB feedback:
- I think no tags is a good idea, very implementation specific
- I think it's a fantastic idea, and the initial proposal is very good!
- i need to go, but thanks for introducing the idea, excited to see where it goes!
- Thanks for your proposal. I really hope it will work out.
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"]]
|
