Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.

[1] https://github.com/tecosaur/Org.jl

[2] https://github.com/amake/org_parser

[3] https://github.com/nvim-orgmode/orgmode



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.


I can't imagine the use cases for parsing org-syntax in Julia - is it for textual analysis?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: