LilyPond is the best way to integrate sheet music into the text-only formats (Markdown, wiki markups, org-mode). MediaWiki supports LilyPond. Emacs org-mode supports LilyPond. In fact LilyPond is way more simple to make small score snippets than any WYSIWYG score editor.
Google Docs are incompatible with complex formatting (LibreOffice and even Office365 are too). Moreover, even the Word itself is kinda incompatible with complex formatting: sooner or later one of your collaborators will copy/paste some text with a formatting you will be just unable to change/clear.
Anyway, Word «collaborative» features are so much worse than git repository and pull requests! And even you need to collaborate with some extremely non-technical folks, in the case of LaTeX they still use add comments to the PDF file — and this workflow is still way more productive than editing the same Word document.
Other reasons to not to use Word in collaborative pipelines are already mentioned in neighbor threads.
Of course you can choose what you use for your personal pipeline.
But Word for collaborative work is a nightmare. Sometimes fastest way to work with the science text or documentation in a Word document is to hire a freelancer to retype all the text in LaTeX or something else.
It's a kind of Trolley problem: sometimes Word fanboys, unfortunately, _should_ suffer to let all the team get the job done.
All GUI OFM-s I've seen missed the main (IMO) feature of Midnight Commander: seamless integration with the plain shell. In MC I can select files with Ins/*, then run command with %t macro to process selected files, then press Ctrl+o and look to the shell output, then maybe run some other shell commands in the full-screen mode, then press Ctrl+o again and return to the dual-panel mode. Moreover, I can edit shell script with the embedded editor (F4), then press Ctrl+o, run the script, read the output, press Ctrl+o and edit the script if needed.
Sorry, but _what exactly_ «it seems to do» from your point of view?
My «second brain» now is almost 300Mb of text, pictures, sound files, PDF and other stuff. As I already mentioned, it contains tables, mathematical formulae, sheet music, cross-references, code samples, UML diagrams and graphs in Graphviz format. It is versioned, indexed by local search engine, analyzed by AI assistant and shared between many computers and mobile devices. And (last but not least) it works: it allows me to solve my tasks way more faster than with the assistance of external, non-personalized tools (like ChatGPT, StackExchange or Google).
I know no tools for all this tasks except org-mode. Well, maybe Evernote in the 2010-s was something similar — but with less features, with more bugs and with worse interface.
Personal note-taking _is_ a complex task per se (well, at least for someone like typical HN visitor). I've seen many note-taking tools, that were ridiculously featureless, stupid and inconvenient because they were _not_ complex enough.
> Sure if one wants to do emacs-gardening it is fine.
2)Org-mode works in Emacs out of the box, you don't need any «emacs-gardening» to use org-mode.
3)The term «Emacs-gardening» itself sound a bit like hate-speech for me. The complexity of Emacs customization is overrated, mostly due to opinions of people who never used Emacs or used it in the previous millennium.
I used org-mode files to save the examples of complex commands and code snippets (for example, for Docker, Kubernetes, bash, SQL and CQL). From the reader point of view it's literally documentation, although I'm not a professional technical writer and the only reader it's just myself (ok, sometimes I share some of this files with friends and family).
If you use Emacs, you will have great editor with powerful preview features (images, formatting, table processor with formulae, code execution inside the text), and the pipeline for generating HTML or PDF will be approximately the same as with .md/.rst (org-mode is even supported by GitLab and GitHub web interface, although not perfectly). But the support of the org-mode outside Emacs is worse than of Markdown and reStructuredText.
IMHO you don't need org-roam to use org-mode for note-taking. I use a bunch of plain org-mode files (synchronized between my computers and mobile devices with git and Syncthing) for my notes since 2016, and for me it's the best «second brain» solution I've ever seen. LaTeX formulae! Sheet music (with LilyPond)! Of course, less exotic things like pictures, links, tags are also supported.
I tried to use org-roam, but it's too complex to adopt my already written notes to the org-roam format and structure.
I found what is «Morphic», mentioned by Richard Feldman.
It's an another experimental programming language with the static reference counting. «Morphic uses a borrow-based reference counting scheme which is able to eliminate almost all reference count increments and decrements for a large class of programs»ⓒMorphic developer team.
IIUC recursive data structures like linked list and trees are not the problem for the static reference counting. Mutation (and, therefore, link cycles) _is_ a problem, but Roc is a clean language with no explicit mutation. =)
> I can see so many basic cases in which it doesn't work
Sometimes runtime reference counting is still used. But, of course, in way more complex situations than just processing a linked list.
> Nitpick: Rc and Arc are not traits.
Of course, my fault. I haven't written on Rust for a long time (and never used this language in a serious project).
Rc and Arc traits are implementations of the _runtime_ reference counters. Runtime reference counting is sometimes less efficient than tracing GC.
But Roc counts references in _compile_ time. So it's like _usual_ (not wrapped in Rc<>) values in Rust. But in Rust the value is deleted from the heap when the stack frame with the _only_ link to it («the owner») is deleted. And in Roc the value is deleted from the heap, when the _last_ link to it leaves the stack.
So we have the machine code _almost_ as efficient as a Rust-produced machine code, but the source code with a much simpler semantics.
Definition of resulting code as _deeply_ imperative was crucial in my phrase.
The only «sine qua non» optimization through opportunistic mutablity is AFAIK tail call optimization. But it is probably too well-known to call it «clever optimization» in 2023.
But, for example, applying a function to a list will produce the code allocating new list in, say, OCaml and Haskell, at least by default. And Roc will produce the code for mutating the list in-place _from the source code with the same semantic_ (see example for the Quicksort algorithm in the video above).
Compile-time lifetime analysis (that probably is not needed at all in functional languages with GC) and widely used unboxed values are way not common in functional language implementations. For example, in OCaml those features are still experimental (and probably never will be used by default, as in Roc).
If you are interested, «why yet another programming language?».
The unique selling point of Roc is clever optimization to convert purely functional source code to deep-imperative fast machine code, while keeping all the correctness of functional algorithms.