RE: https://mastodon.social/@jarango/116047121332640221
Reminds me of "Dominik's tenth rule: Any sufficiently complicated #PIM or note-taking program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of #Orgmode."
Today they're adding a CLI.
Next a REPL.
In a couple of years maybe a decent programming language.
If you want all the fun just now without the lock in effects of #Obsidian, take a look at the cool features of https://karl-voit.at/orgmode/ 😉
@jarango Everything true.
However, I disagree with #Markdown: https://www.karl-voit.at/2025/08/17/Markdown-disaster/
It's way more open than, let's say, #OneNote & so forth. Unfortunately, it's far from being a #textformat that can be reused anywhere without problems. At least I need to convert MD all the time from one flavor to a different.
With more and more #Obsidian add-ons introducing their own syntax elements, you will end up with clear text files you still can't convert for a different tool without modifications. Good luck with finding out which elements are going to survive and which not. For a few files, that seems OK. If you have a decent #PKM like you describe in your awesome #DulyNoted book, it requires more effort.
For everything I need to use with #MD, I keep a syntax file with one example element so that I keep an overview & know what to convert how in case I need to reuse information stored in this MD flavor.
With org, I just push it through #pandoc & I'm done. 🤷
"Potential #Markdown Data Loss When You Will Move Away from #Obsidian"
https://Karl-Voit.at/2026/04/08/obsidian-md-portability
In many discussions, users of tools like Obsidian did not understand the somewhat abstract/generic warnings in my article on Markdown: https://karl-voit.at/2025/08/17/Markdown-disaster
So I asked Claude to generate a concrete list of problematic #MD syntax elements when you will leave Obsidian.
Plain text is not everything. You still need to make sure that your (meta-)data survives conversions of problematic MD flavors to target formats like other MD flavors or (in my example) HTML.
Please do report back in case of LLM hallucinations.
Edit: there do seems to be issues with the LLM result. Until manually confirmed (this is going to be time-consuming), do not trust its output literally, get the idea behind the warning and check your own data with an example export.
@publicvoit There are a number of basic errors in this report, but since it's LLM-written I suppose I shall put as much effort correcting them as you put into generating them. Sigh.
There's an Obsidian extension for Pandoc so you can convert your Obsidian notes to any other format. It's no different than the workflow you described for Org mode.
@kepano I was as transparent as possible about the LLM-character of that article - my first one, btw.
For an article that tries to help users of #Obsidian although I don't use it myself and although I already wrote an extensive separate article that should cover the basic premises, I do think the hour spent was quite adequate.
I took great care to come up with a decent prompt, checked the output to find indicators of hallucination and spent time to make the complex syntax work with my blog generating software.
The link you provided is helpful for a subset of the issues (comments and internal links only, as far as I see), thank you for that. 🙇
But other than that I would love to learn about the things the LLM got wrong because I doubt that all the rest is based on hallucination.
After all, it's a conceptual issue that relates to all tools using #Markdown in a non-trivial way.
@publicvoit It's hard to muster the energy given it's LLM-generated. Non-exhaustively:
- Pandoc can convert Obsidian formatting losslessly
- Obsidian provides compatibility toggles e.g. to disable wikilinks
- Everything marked "Obsidian-only" is not
- Callouts are in GFM and other apps
- Interleaving extension syntax is misleading
I find it incredibly lazy and disrespectful to share this without basic fact-checking then give it a clickbaity that doesn't even match what the article says.
@kepano Yes it was lazy as I explained why and how I did it that way.
However, it was as transparent as possible including LLM-warning, original prompt, ... so you can't say that it was disrespectful.
I added a more than clear warning to the page title and content.
Until I find time to do this tedious checks manually, it'll have to serve as a general warning for certain lock-in situations.
@publicvoit I understand if someone prefers to use standard Markdown links over wikilinks for interoperability (despite the fact that many tools now support wikilinks in .md), that's why Obsidian offers that toggle.
To suggest that because Obsidian will render Mermaid or LateX syntax if you insert it means you are going to have data loss is objectively nonsensical.
I would expect a minimum amount of rigor if you're going to make that claim.
https://en.wikipedia.org/wiki/Extraordinary_claims_require_extraordinary_evidence
@kepano I can folllow your rationale and argument from Obsidian point of view.
My claim is in https://karl-voit.at/2025/08/17/Markdown-disaster/ and I constantly meet Obsidian users that don't understand that claim or think that it doesn't affect their situation.
While I agree that you may use some Markdown tools in a way that you keep your ability to re-use data without conversion and stuff for a migration process, the average situation is most likely a different one.
Therefore - and for the first time - I thought that an AI generated concrete list of issues related to Obsidian is more helpful than my generic description of the issue in my article above.
This seems to have failed which is a pity.
So, yes, if your claims are true (and I trust your judgement here), then this article needs to be written again or deleted. I just need to find time because I still like the general idea for such a guideline or summary.
Karl Voit 
Jorge Arango
kepano
