Yeah, it's a bit of a bummer. Getting the basic structure is easy, but when you start mixing in inline latex + source blocks + tables + deadlines things get really hard really fast
Also, persisting things as text isn't really the best persistence mechanism with respect to merging simultaneous client edits anyway. Not only would you have to write a parser for something where the spec is just a pile of semi-related elisp, but you'd have to write an editing algebra over that AST that would allow you to nicely serialise edits. As someone who has tried editing org files on the go on their phone with orgzly and committing to git; the conflict resolution strategy of line by line diff edit merging is not fun.
Probably the right thing to do would be to first write a specification for some subset of Org (since that would benefit both the parser project and the Org project) and then extend that. https://orgmode.org/worg/dev/org-syntax.html is something, but I'm not sure how binding that is. Might just take some work to stabilize it and get it standardized.
Someone should write an orgmode parser using
megaparsec
.Interesting project idea. What would be the use case for it?
Writing a (interactive) reflex based UI for diary entries stored in org files.
Properly parsing org is a nightmare
There isn't a formal spec, and it's insanely complicated
Yeah, it's a bit of a bummer. Getting the basic structure is easy, but when you start mixing in inline latex + source blocks + tables + deadlines things get really hard really fast
Also, persisting things as text isn't really the best persistence mechanism with respect to merging simultaneous client edits anyway. Not only would you have to write a parser for something where the spec is just a pile of semi-related elisp, but you'd have to write an editing algebra over that AST that would allow you to nicely serialise edits. As someone who has tried editing org files on the go on their phone with orgzly and committing to git; the conflict resolution strategy of line by line diff edit merging is not fun.
Maybe I complicate matters by my entry level org mode needs requiring org-brain for better hyperlinking between entries, lol.
But it fell off the rails super quickly even with a pretty good existing org UI.
Probably the right thing to do would be to first write a specification for some subset of Org (since that would benefit both the parser project and the Org project) and then extend that. https://orgmode.org/worg/dev/org-syntax.html is something, but I'm not sure how binding that is. Might just take some work to stabilize it and get it standardized.