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. 🤷
@publicvoit @jarango FWIW there's pandoc support for converting Obsidian Markdown to other formats. I added it a while ago but it hasn't been merged yet:
Add Obsidian-Flavored Markdown #9883 using Markdown extensions. Extensions comments: Parses %%text%% as comments (removed from output) wikilink_transclusions: Parses ![[Title]] for full file trans...
"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
I don't see anything about *data loss* in this article, only about degradation in the rendering outcome if comparing Obsidian rendering to Pandoc rendering.
As a side note: reading this cost me more time than adding mermaid rendering to my static site generator, which is fed by obsidian flavored markdown.
So, while the grievances are real, the impact in real life is neglectable.
@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.
"But other than that I would love to learn about the things the LLM got wrong"
I doubt that many people here will proofread a LLM generated text for you. For me it just ain't worth the time.
@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.
@publicvoit furthermore it's hard to have a conversation when I read this:
> The link you provided is helpful for a subset of the issues (comments and internal links only, as far as I see)
You didn't even bother to read past the first bullet point.
@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.
@kepano Are there any Obsidian resources that summarizes the things to do in order to prepare for data compatibility and how to convert as much as possible to other formats?
Is there a recommended way of doing so? Should I take pandoc? Should I look for some Obsidian export add-ons? ... that kind of stuff.
@publicvoit Im looking at the hype on the obsidian website thinking “how many of those benefits can I get using a single sheet of paper and a pencil.
I’m running an experiment. Paper vs denote.
@eludom There are awesome paper based methods out there. For example #BulletJournal.
However, that's focused on todo and project management and not so much on #knowledgebase management.
The original #Zettelkasten method was on paper and for that purpose.
Digital methods scale much better and require less effort though IMO.
(fixed interestingly wrong language tag)
@publicvoit Yes, I know you’re right (and have studied it way more than I ever will).
Shiny marketing web sties (obsidian) activate my contrarian instincts and make me think “how can I solve this problem without funding your home on the golf course” ?
@[email protected] 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. 🤷 #publicvoit #LML #Zettelkasten
@publicvoit I love Org, but Obsidian is fine. I don't know about its latest features (Bases or its LLM integrations) but for keeping a notes archive, an Obsidian vault isn't locked in at all. With an Org plugin it's even able to open my main notes archive and interop with my notes just fine.
(Coming from the Org world I also don't think we get to call Markdown or Obsidian informally specified or slow. Org is no Common Lisp, unfortunately. Which is fine, but it's fine for both.)
@publicvoit That issue is with extra syntaxes that represent unique features, and that is indeed something to be wary of. But GFM is still a perfectly fine portable core syntax that many platforms (including pandoc) already fully support. In terms of lockin, Markdown is also fine.
Markdown allows in-word ita*lics* which is very necessary in languages that don't use spaces; Org has far better properties and outlining; so I use both and neither is strictly worse than the other
@kisaragi_hiu If everybody and any tool would limit itself to GFM (or any other well-defined Markdown flavor), then I'd agree.
I don't see that in practice.
Therefore, I may convert or reuse any orgdown file with any tool. This is not true for Markdown - which I need to use on a daily basis as well. It's a chaos and therefore I'd like to warn people about the subtle and not so subtle lockin effects of plain text formats: https://karl-voit.at/2025/08/17/Markdown-disaster/
Karl Voit 
Jorge Arango
tusharhero
kepano
Lamont Sky
George Jones
Drea
如月飛羽🌈