thank fucking god for org-mode
the main problem with org-mode is still that collaboration is hard :\
but I guess we already discussed that in @librelounge episode 1 so I don't need to repeat myself here!
@cwebber Isn't that true of, like, most editors most of the time?
@astraluma yeah but org-mode becomes A Lot Of Things including project management, so collaboration tends to come up. And you might say, well, check it into git (good idea)! The challenge is, org-mode also encourages customization, so your org-mode and my org-mode might become different ;)
What that means is that you can't operate atomically on the data easily. Emacs is always operating on the files, without the abstraction layer.
It's what makes org-mode so powerful and extensible, but without some kind of abstraction layer that Emacs could manage, there's no way to improve the situation.
I wonder why no one has done this? Maybe it's too hard? You'd have to do it in something like Canvas... with its own fonts and stuff, but would it really be that much harder than GTK?
The problem is that the format is so complex and deeply tied to the rendering that every time anyone tries to replicate all the functionality, it fails. I don't think these developers are dumb. That means we have two choices:
a) Abandon org-mode.
I don't want to but I am bumping up against too many limitations
b) Make emacs talk to the rest of the world
@astraluma @emacsen @cwebber The only thing I dislike with org-babel is the default evaluation of emacs-lisp code blocks. Emacs-lisp is cheating, since it has access to the whole org-mode API, and the even wider emacs API. So in fact, this (and the other small places where you're allowed to write emacs-lisp, like in macros and tables) means that if you want to be part of the org ecosystem, you need to implement emacs. This is sad for interoperability :(