I have no problem with there being options for devotees of historic markdown formats, so long as it doesn’t detract from my own usage. I’d certainly resent it if it did because I accepted the default as it was designed and don’t see why it should be degraded for the benefit of those who didn’t accept it.
However, most of your post is pure polemic full of inaccurate statements that markdown purists have convinced themselves are true because Gruber said so.
Markdown is NOT human readable. It can be deciphered, but only if you know the syntax. The only format reasonably guaranteed to provide longevity is pure text. Markdown doesn’t actually conform to the norms of pure text because of its misuse of the indent. AsciiDoc is better designed but much less common.
This isn’t true. It’s a question of where you look. New programs with extended functionality are tending to wikilinks. No vendor lock-in, and probably more compatible with programs of the the future than programs of the past.
Even in plain markdown editors there is limited compatibility. I use few of the markup features, generally preferring to stick to to text. Nevertheless, I have to test all the common features I do use to see if they allow the syntax I prefer or not - and that’s limiting myself only to editors that claim to follow Commonmark/GFM. ‘Lock-in’ is either endemic or non-existent. Being able to switch from one syntax to another or bulk convert documents is par for the course.
And resorting to rhetorical sleight-of-hand by using statements like “Zettelkasten pro users” in a community where many are only just familiarising themselves with the concepts is simply unfair. And I’m sure you must be aware that there are some ultra zettelkasteners who insist that only handwriting on cards in an index box is true to the system - and they do have evidence to support their claims of it being more effective practice. And paper is more guaranteed to last than any digital format.
@Dor just to be clear: IMHO, the use of WikiLinks is a great addition to Obsidian - and should definitely be kept. My point is that because Obsidian’s philosophy is based on not locking-in the user, they should not be offered as the primary solution. As much as we might like them, they are proprietary - and not as widely adopted (or standardised) as we might think. Compare how it’s done in The Archive, DEVONthink and Bear apps.
Obsidian is doing a fantastic job in trying to balance the need to provide users with great functionality, while trying to maintain the format longevity required by Zettelkasten - that is not an easy task. Like you said, on one hand we have ‘purists’ who think the only solution is to use pen & paper index cards. On the other hand we have software that provides users with amazing features but use totally proprietary formats - like the amazing Tinderbox. Most software falls somewhere in the middle - like Bear, Ulysses, The Archive, DEVONthink, and many others - by using some proprietary markup.
It would be a very big bonus for Obsidian, if it were to allow users to stick to fully-standard markdown syntax - as default. As I pointed out above, I don’t think that there would be much work needed. The main difference would me a conceptual one: by making the standard markdown links the default, and WikiLinks an option, Obsidian would be sticking to its philosophy, while still providing the users extra features - if they don’t mind the lock-in.
Since the original post actually contains two suggestions, I’d like to archive it. In 0.6.6 (link to changelog), we have done quite some work to make Markdown internal links work as closely to internal links as possible. Namely, navigation works, they are properly indexed for graph view and backlink, link update works, and even page preview works.
So what’s unavailable right now are (1) having auto-complete enabled for Markdown links and (2) making Markdown links the default.
Feel free to make requests for (1) so we can keep track of them separately. (2) is less about having and more about design philosophy if I understand correctly, so probably posting under the “Obsidian” or even “Knowledge management” category would make more sense. Feel free to copy over any existing discussion that’s relevant.
We’re not sure about auto-complete Markdown links by default because pure Markdown does not differentiate between internal and external links. I imagine having auto-complete always show up would throw people off.
Or maybe a customizable hotkey to insert internal Markdown links would make sense.
@Silver thank you for your attentive and friendly feedback!
In regards to differentiating between ‘internal’ and ‘external’ links, perhaps Obsidian could just apply some basic path analysis - it would probably cover most use-cases - like this:
if path is local (no protocol at start), assume it’s an internal link, else
if protocol is “file:”, assume it’s an internal link, else
I’m copying a comment from @ShaneRobinson in this thread to provide a different perspective in support of standard markdown links, namely in being able to be used in a Github Pages/SSG site, not just as a local PKM tool, which is my desire and surely that of many others.
Blockquote
Oh… Yeah. You’re correct that MediaWiki-style [] links don’t work or convert to GHPages or an SSG (like 11ty, Hugo, etc…)
I don’t use [[]] links in Obsidian. I use standard Markdown text format which works perfectly in Obsidian. And allows me to “lable” the link anything I want instead of whatever the File Name is.
I also have TextExpander quick keys that generate an entire set of FrontMatter Keys and Values at the top of each file. Again, I’m working mostly in VSCode and only use Obsidian for viewing the Graph or backlinks…and with FOAM there’s less round-tripping between VSCode and Obsidian.
For me, I’m really not concerned about the Graph or backlinks when I’m working/writing.
My thinking/process is basically:
1. In order to maintain as much open format and interoperability in the future, stick to content and file format standards.
2. For the few internal/external links in each document, it’s not that much of an inconvenience (especially with quick keys) to use standard text syntax. This ensures I can serve any .MD file I have with any SSG and/or use any standard Markdown converter now and in the future. And when I’ve finished the document, I do have to manually at Tags to the Frontmatter “tags” array. Adds 2-3 seconds per tag, but guarantees I’ll have taxonomy connections between files when published through an SSG.
3. Placing Frontmatter at the top of each file also guarantees future interoperability, conversion, and hosting via SSG. Using TextExpander makes this super easy and fast.
It’s that old tradeoff of simply changing a few workflow elements (using text instead of [] for example) to benefit from exponentially more interoperability.
I’m all in favor of keeping Wikilinks, and am relatively indifferent if its the primary link method or not. But what would be good is just to have a similar search/autogeneration function for markdown links. Or even a tool to convert wikilinks to markdown links (with the page title becoming the link name, unless there is an alias).
it’s possible to use specific plugin converting [[ links to standard one in Jekyll or Gatsby …
WikiLinks is a great addition to Obsidian - and should definitely be kept. My point is that because Obsidian’s philosophy is based on not locking-in the user , they should not be offered as the primary solution. As much as we might like them, they are proprietary - and not as widely adopted (or standardised) as we might think. Compare how it’s done in The Archive, DEVONthink and Bear apps.
I disagree. Wikilinks [[ become more and more adopted. Drafts and Tinderbox adopted it lately (even if this is an artificial similarity because in TB imported markdown files [] links doesn’t work); The [[ links are understood by Zettlr, and even The Archive …
Instead, I would support setting links to “normal markdown” when exporting (if this option will be created or someone will build as a plugin)
You suggest that Wikilinks are becoming a standard, but 3 of your 4 examples are Mac-only, and the 4th (Zettlr) has a very small user base when compared to note-taking software generally. Your evidence is thus insufficiently persuasive. We should have support for real Markdown links.
[1] The [[ solution is not “tool agnostic”, is it?
[2] The most valuable asset to preserve in a zettelkasten are the connections between notes, are they not?
Bear, Devonthink, The Archive, Draft, Zettlr, Tidlywiki, nValt are using [[ ]] syntax …
The argument that most of it are Mac are proving only that most of the developed note-taking mac is for mac and the other OSes dont have that many nice tools …
In general backling-linking not taking approach is just gained popularity and I think the user base will be growing
I’m not against support real Markdown links, not all app support [[ ]] or support it in different way (so there is a with linking notes nested deep in folders) but this will be changing.
Having read this thread (and also other related discussions) in this forum (and also outside this forum), I still feel I haven’t received an answer to a basic question that currently haunts me:
should I - from the start - work with wiki or markdown links as the default?
Given that:
I want all my notes and links as future-proof and app-independent as possible;
In obsidian, as far as I can see, both link styles work the same, without any limitations (including the backlinks function) - am I right?
So are there short and simple arguments concerning the following question:
What would be the advantage of wiki-style links as compared to markdown links (or the other way round)?
Apart from that it’s a question of whether you want to maximise compatibility with the past or future. Most of the newer link based apps use wiki-links and older ones are introducing them. Most traditional markdown editors use markdown links, though a few have added wiki-links.
Making the links future proof does mean that you need to predict the future.
I suspect there will be conversion utilities around for quite a while.
After thinking about this subject, dealing with bug reports, etc. I’ll give my argumets for wiki-style links.
Negatives of Markdown links:
They are way more move verbose, and you should use %20 or <> to handle whitespaces.
There is no (easy/natural) way to define a link to a note that doesn’t exist yet but might be created in the future (or if there is a way, it’s implementation nightmare)
There is no spec for linking to header (but maybe there will be one?)
They are not as easy to work with from an implementation standpoint.
Negatives of Wiki-Links:
There is no spec for wiki-link, but given how popular they have become and how many devs are implementing them, I am confident there will be one.
@Dor and @WhiteNoise, thank you both for your short and clear replies!
@WhiteNoise, the negatives you mention refer to markdown in general, I understood? Because all this stuff works perfectly within obsidian at least - actually both markdown and wiki links work exactly the same here (no problem linking to headings with markdown links either).
And you’re right, links to headings aren’t understood by other markdown editors, but at least they open the respective file for you when you click on the link - yet I just tested wiki-style links in 3 different markdown editors (re-text, ghostwriter and typora) and all three even didn’t recognize wiki links at all…
So I’m still not completely convinced, even if I like the idea of wiki-style links. But what I take from my experiments so far is the following:
within obsidian it doesn’t matter anyway - it all brings you to the same results;
but markdown links can at least be opened in any other editor (even if it doesn’t take you to the exact heading), whereas a couple of editors doesn’t recognize wiki links.
Actually, for now, only a small number of editors do recognise them.
It’s important to understand the difference between the links and their use cases.
Standard markdown was for web pages etc. Links were infrequent, usually to external files but with an option for internal. Documents were otherwise standalone just like a word processor.
Wikis were all about links, mostly internal.
The first placed most reliance on specifying the precise file and path - speed mattered less because they were done less.
The reverse for wikis because linking was done so often the wiki was its own construct so there was no gain spending time specifying file and path more than necessary.
Obsidian and the other knowledge based note programs are built around linking and so ease and speed matters. That’s why they all go for wiki-links. They all, more or less, go for markdown because it is plaintext (therefore easy to process) and is a pre-existing standard of sorts. They all add extensions when they need something that doesn’t exist in a markdown standard - nothing new there.
Realising the power and popularity of the linking paradigm, older programs are rushing to add wiki-links.
Editors don’t have the same need, and most of their users are just using them as document processors. They will change slower, and only if they perceive their users regarding it as a must have feature.
I think that day will come, you may not.
For now standard links will cost time and effort in Obsidian and other programs that allow wiki-links.
Wiki-links will cost effort and probably time if you often use editors that don’t understand them.
The best future proofing guarantee is the ability to convert (Obsidian has said it will provide a converter to standard links).
Would you be willing to give some examples of these older programs? If I’ve used (or am using) any of them it might give more understanding of the nuances regarding wikis.
Thank you so much for listening to your users and implementing this feature. Is it possible (or could it be implemented) that there’s a setting to use relative links and to create a hard-coded backlink with standard markdown links?
I have an existing markdown notes library that I’ve curated by hand (with some help from VS Code extensions) and feel drawn to Obsidian because of its mission to use a vendor agnostic format like markdown. However I’ve been burned in the past by adopting ‘flavors’ of markdown that were promised to be gaining popularity and widely supported. I’d like the option to, by default, use standard markdown reference style linking.
This feature seems to allow that but does so without acknowledging folders. I.e. Obsidian will do [Folder/note](note.md) instead of [note](./../folder/note.md). This seems to break in any other editor I tried. The functionality I’m envisioning is:
I have folder structure:
folder-a
– note-a.md
folder-b
– note-b.md
In note-a.md I type [[note-b]] at the top of the note
This expands to:
[note-b][]
This is some other text in Note A
[note-b]: ./../folder-b/note-b.md
In note-b.md
Some text I already had in note b
[note-a]: ./../folder-a/note-a.md
This is a clean way for both notes to have a strong connection using standard markdown syntax.
Perhaps I should just create the VS Code extension myself, but judging by this thread there’s a solid interest in standard markdown linking. Also, I love what you’ve done with Obsidian and would love to dive in head first. This is the only deal breaker for me.
