3 ms·

It does kind of bother me that Org doesn't have a particularly good formal spec. There are a ton of parsers out there, which is great, but there is no Emacs-in

It does kind of bother me that Org doesn't have a particularly good formal spec. There are a ton of parsers out there, which is great, but there is no Emacs-independent set of tests you can run against a parser to figure out if it's compliant. Ultimately, the Org format is what Emacs says it is, and everyone else just tries to play catch-up. I feel like this is a little bit of a missed opportunity. I use Emacs because I think it's (for me) the best editor that exists today, and it's likely to continue to be the single best editor that exists (for my needs) in the near-to-long-term future. That doesn't mean I'm necessarily pleased about how much Emacs tends to suck features into itself and how hard it is to get them out. I don't like that the "canonical" version of Org-mode is Emacs dependent. I don't like that when I manage my life through Org-Agenda it becomes needlessly hard to work with other tools unless I sit down and find a partially functioning Org parser on Github that may or may not be abandoned. Yes, Org is plain text, but being plain text isn't good enough, it also needs to be easily parseable into a consistent AST or formal data structure on multiple platforms. I don't like that when I write a tool in Emacs Lisp that I can't run it headlessly anymore, and that it now requires a massive pile of dependencies to run. The Tern language server was a good development on this front, it's good for language formatting tools to be separate from editors. I wish more parts of Emacs would work that way. But it's not so much of a problem that I'm willing to give up Emacs to in order to cobble together a system that adheres more to the Unix philosophy of being more composable. The lock-in effect is definitely real, it's just that Emacs also happens to be good enough right now that I don't have anything else I particularly want to move to, which makes the lock-in a lot less annoying. I'd move off of Emacs if I felt like any of the other editors were better, but I don't, for me none of them come even close. Emacs has a huge community and a huge featureset that dwarfs other editors, and it also has this core of flexibility and transparency and extensibility that I feel even "configurable" editors like Visual Studio and Atom haven't really caught up with. But importantly, me saying that Emacs is the best editor around is not quite the same thing as me saying that Emacs is good. I don't have any regrets picking up Emacs, at all, it was a great choice and it's paid off tremendously, and I think it'll continue to pay off in the future. But I do wish there was a better editor out there.

neolog 5y ago
What is the advantage of plain text? Other than that Emacs is bad at editing other file types.
- danShumway 5y ago
  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.
  - neolog 5y ago
    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).
    - danShumway 5y ago
      > 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 :)

neolog 5y ago

What is the advantage of plain text? Other than that Emacs is bad at editing other file types.

danShumway 5y ago
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.
- neolog 5y ago
  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).
  - danShumway 5y ago
    > 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 :)