I used Orgmode for years, but I think fundamentally tieing your markup to your editor is kind of a bad sign... I'd be curious to hear counterarguments though. I think the primary reason it's tied is because you sort of can't make standalone ELisp apps (or at least nobody does). Otherwise you'd just have an `org2html` and `org2pdf` application at the command line.
Alternatives like Asciidoc are not perfect, esp for literate programming, b/c it's also kinda complex and so it also only has one backend (that's runnable from Clojure through JRuby!). I imagine a simpler multi-backend solution like Djot will be the future most likely. Bloated underspeced markups are on the way out.
Well if you don't do that, you would only have a lowest common denominator system with none of the advanced features, and the world has enough of those.
If I wanted to emulate a fraction of org-mode features I use daily in markdown, I would have to use Obsidian with a bunch of plugins, and we would end up in same boat.
I don't know the exact spec situation, but I know that comprehensive parsing libraries in modern non-elisp languages exist. An org-mode contributor has one in Julia[1], another in Dart[2] that powers a Flutter app, and there are many tree-sitter grammar based tools that are useable from neovim (e.g. [3]). The basic org2html or org2pdf CLI needs are already addressed by Pandoc.
The format/spec isn't really the problem. It's just that parsing and rendering Org Mode files is like parsing and rendering .PSD files - getting your app to open and write PSDs alone does not turn your app into Photoshop; you're still missing 99% of the features.
Right but if you implement the rest of the features, you become an org-mode IDE anyway. I don't mean that's a bad thing, syntax is just bare minimum, most usefulness comes from interactive developer experience anyway. I was just addressing the point parent raised that marrying markup with IDE is a bad idea, and that when it comes to syntax org-mode is hardly underspecified compared to other markup languages.
Would it be neat to have an alternate complete implementation of org-mode elsewhere? Sure. But unlike say Photoshop, Emacs is already open and extremely hackable. That mitigates most of the reasons you would want to.
Well, there's org-mode plugins for vim and vscode, github displays it just fine, pandoc processes it, there's a syntax specification at https://orgmode.org/worg/dev/org-syntax-edited.html, a separate clojure implementation at https://github.com/200ok-ch/org-parser using EBNF, several Android and iOS apps. And Emacs has been around long enough that it's likely to keep being around for at least as long (see Lindy Effect).
Org is hardly more tied up to the editor than any of the many other formats people use – all of these have more or less complete editor support depending on what features you need (e.g. if you start doing fancy literate programming in markdown, or azathoth forbid, try commenting out lines, you'll find spotty support in at least some of the existing implementations). And if you like the full combination of features that Emacs+Org gives you, you'll be hard pressed to find another environment to replace that, so ... why bother?
(OTOH if you only need some minor part, like html export, and you have to work with people already using other formats, then those other formats might be better.)
>you sort of can't make standalone ELisp apps (or at least nobody does). Otherwise you'd just have an `org2html` and `org2pdf` application at the command line.
Because I don't like emacs and I wanted to lean on command line apps for getting data into and out of my orgzly org-mode electronic brain, I've been doing this by combining orgmode with jinja2 (I do this with a cli app I wrote called 'orji').
I think it's a very powerful combination. I use it to generate latex/html/whatever and short bash scripts which are then run. E.g.
* Generate my CV using a latex CV template I found on overleaf that I converted into a jinja2 template.
* Send the contents of a TODO note tagged 'sendemail' as an email with a tiny templated bash script.
* Create jira ticket with the details of a note.
* Generate reveal.js presentations.
All from my phone, using orgzly and one big button which runs a single termux script that seeks out TODO notes with labels (e.g. cv/sendemail) that match the scripts in my library (cv.sh / sendemail.sh).
jinja2 certainly has the capability to end up creating a huge old mess if you abuse it, especially to generate code, but I find that using it to template tiny 5-6 line bash scripts or a latex or an HTML file hits a sweet spot of usability and flexibility.
A link to the documentation¹ and repo² to save others a few steps. Examples are helpfully linked toward the end of the page and its source in the README.
> I used Orgmode for years, but I think fundamentally tieing your markup to your editor is kind of a bad sign... I'd be curious to hear counterarguments though.
For better or worse, Org Mode is a feature-rich application, and org mode format is markup tied to that application. Using it as general-purpose markup is kind of a nice side effect of it being plaintext, and that even the portable subset is more feature-rich than most markup alternatives.
For full compatibility, you'd have to port Org Mode to different editors, in the same way you'd port a native app between OS-es. Org Mode is very much an application that's making full use of its platform's specific features and APIs, except here the platform isn't Windows/Win32 API, but Emacs/Elisp.
Org mode is a markup language in the same way as Emacs is just an editor. Both are true but do not tell the whole story. Org is a plain text application framework built on top of Emacs platform.
My favorite is Org Babel (jupyter notebooks on steroids) that can be used for literate programming that you mentioned (reproducible research, devops-y tasks).
Publishing is just one of many applications. There are certainly cases where you might want a more specialized tool.
I daily-drive Emacs, and write my website/blog [1] in org-mode, but I use pandoc to compile org to HTML [2]... This choice was critical for me. I did not want my publishing workflow to depend on Emacs!
It's true that Emacs is the canonical Org-Mode compiler, but there are many other compilers, including Github pages. If it's typesetting you want, the support is widely available. If it is org-mode-powered workflows (like TODOs etc.), then support outside of Emacs is narrower, but still quite serviceable [3].
__shite_templating_compile_source_to_html() {
# If content has front matter metadata, it is presumed to be in a format
# that the content compiler can safely process and elide or ignore.
local file_type=${1:?"Fail. We expect file type of content like html, org, md etc."}
case ${file_type} in
html )
cat -
;;
md )
pandoc -f markdown -t html
;;
org )
pandoc -f org -t html
;;
esac
}
I did many applications, I just did not publish them.
It is great when the applications need to generate reports, for that I used org mode and then exported in LaTeX, generating a PDF at the end.
Alternatives like Asciidoc are not perfect, esp for literate programming, b/c it's also kinda complex and so it also only has one backend (that's runnable from Clojure through JRuby!). I imagine a simpler multi-backend solution like Djot will be the future most likely. Bloated underspeced markups are on the way out.