I haven't really tried writing large pieces of text in it but I am already seriously considering. All other alternatives are too complicated and have a learning curve that gets in the way of writing itself. With XML, I'd be able to define my own tags and run them by a parser later on to auto-generate indexable footnotes, and create my own ways of structuring text besides the usual ones (chapters, sections, etcetera). Has anyone tried this approach?
Writing documentation as XML is powerful but not enjoyable at all I guess
DITA's benefits require a certain scale that most tech companies never achieve. And the Open Toolkit is a nightmare piece of software.
OxygenXML makes the OT much more manageable. I haven't had to touch an OT XSL transform in a few years now. Worth every penny.
This seems extensible to the degree that I want (i.e. semantically rich enough that you can conceivably hang any application from it). But I just can't bring myself to write in XML syntax, especially for maths.
Problem is when people started to build systems upon systems upon something that should not be used for more complicated cases.
Maybe not a problem because I don't care but I just see how loads of things that someone created to be "just that" someone takes without understanding and builds on top instead of understanding limitations and scope of the initial idea or system.
It is "oh it is missing a feature" - where it is "no it wasn't built to do that".
I have seen notepad in windows shipping some formatting features, I don't see that as an improvement. Notepad was notepad for purpose.
Regarding Notepad, keep in mind they dumped an entire separate app (WordPad) by merging the ability to format into Notepad. This kind of mirrors what I was talking about above: one app with a very low floor but a flexibly high ceiling when you want to go there with it rather than two separate apps you need to pick from up front.
1. Spec, written after the fact, not by a core dev.
2. Live help in 'org-info'.
3. Elisp string extraction via 'M-x describe-function' and the like.
Difficulties arise from subtle inconsistencies between the three, and inability of any one to comprehend the kitchen-tool-bin jumble of low- and high-level functionality that has been added over the years.
OTOH, content display is economical of eye and finger effort, and some of the Emacs interaction features startingly powerful.
I wrote my own, use-case specific converter to expand org-format to HTML. Runs on the CL, written in Go.
Having to know and learn 300 clunky frameworks, 97 different syntaxes it gets old.
HTML. CSS. Javascript.
Ask the AI to give me a markdown to html converter, good2go
Why would you do that? There are dozens of libraries which do exactly that. Instead of AI you can ask npm or pip, heck you can even ask CRAN[1].
1: https://cran.r-project.org/web/packages/markdown/index.html
Also modern JavaScript uses import, require() is very 2015. If the AI is recommending you use require() I would suggest a better one.
Seriously though, every time some new hotness comes along, you don’t really have to use it or even waste your time looking at it. Markdown will likely be here after all of its derivatives are long gone.
Basic markdown format is good enough.
For specific cases, it depends what is the outcome - html, pdf…
But hell are binary formats that are used for page layout - vendor lock for centuries. Backward compatibility? Forget about it.
From this point of view people should stick to text based formats. Markdown, LaTex, Typst… you name it. Just use it :)