The ability to hand-parse/edit outside of Emacs, lower risk of data corruption, the ability to read the data visually even if printed or displayed raw. It's nice to be able to `cat` an org file to a terminal or `grep` from the command line, and if a file gets corrupted or messed up it's pretty easy to recover the data.
So basically: transparency, flexibility, portability.
Plain text is great, it's just not enough on its own. Ideally, Org should be both plain text and rigorously defined with a language-neutral set of parser rules that allow it to be transformed into some kind of JSON or similar data structure so that other programs can more easily read and write it.
Org-mode succeeds very well at the plain text, but (imo) kinda fails pretty bad at the "rigorously defined and easily parseable" part.
Increasingly, I think that both are important -- I'm finding that hand-editing Org files and programmatically editing them are both things that I want to be able to do.
Using `cat` is fine but having a format-aware cli dumper would be better. And I never edit org files outside an editor that knows how to handle org files.
I think Clojure's EDN format as used in Roam and Athens does a better job since it avoids the parsing problem while still being easy to fix if the file gets corrupted (though how much of a risk is that these days).
> I never edit org files outside an editor that knows how to handle org files.
I guess I'll also add, I use Emacs in environments where not everyone else uses Emacs, and I like to make TODO lists, write up docs.
Yeah, I can export to HTML, but it's a nice bonus to Org that I don't really have to -- I can write all of my docs and share them with people as plain Org files or stick them on a random flash-drive, and I know they'll still be readable.
Could just be my own disorganization/laziness :shrug:
> having a format-aware cli dumper would be better
My opinions have lately been jumping around a lot on this. In theory, having a good machine-readable format that you can dump out from a command line is enough, because you can turn that format into plain text if it's ever important to do so. So I sort of see where you're coming from.
In practice, I still feel like the lack of friction working with pure text adds something? I do occasionally boot up Vim or stick files on a flash drive and edit them on someone else's laptop when I'm away from Emacs.
But I don't know. Regardless, I do want a format-aware cli dumper, so you're absolutely correct on that point :)
The other thing I meant to say, it's too easy to accidentally mess up an org file while editing it. Manual errors are the most common source of the corruption you mentioned, IME. That doesn't happen with structured editors like paredit.el or Word or Roam.
Word is the worst for accidental manual edits screwing the whole document. I cannot count the number of tines I've watched my classmates manually adjusting dozens of graphs and images in as many pages one by one because they shifted something in inititial pages.
So basically: transparency, flexibility, portability.
Plain text is great, it's just not enough on its own. Ideally, Org should be both plain text and rigorously defined with a language-neutral set of parser rules that allow it to be transformed into some kind of JSON or similar data structure so that other programs can more easily read and write it.
Org-mode succeeds very well at the plain text, but (imo) kinda fails pretty bad at the "rigorously defined and easily parseable" part.
Increasingly, I think that both are important -- I'm finding that hand-editing Org files and programmatically editing them are both things that I want to be able to do.