Wiki vs Markdown Style Links

rrieke

This is just a question for my curiosity, not really about taking action.

If we embrace Markdown's syntax for document structure, why do we make an exception and use Wiki syntax for links? That is, for a link to a sister document, why does [[SisterDocument]] seem to work better than [SisterDocument](SisterDocument.txt)?

The Wiki style is more concise, I see that. But it seems to me there are three points favor of Markdown too:

• It's more completely descriptive, containing both a plain-language description of the link as well as a formal filename, even to a human reader seeing the unrendered plain text
• It could be simpler to remember one markup language instead of that language + exceptions
• Wouldn't HTML (as rendered by a Markdown processor) be more ubiquitous and future-proof than a wiki markup language?

I suspect the answer involves the writing/rendering app itself. I see that in nvALT's (Multi)Markdown preview, a Markdown link fails, with the full URL's path being a clue. When I use Marked, however, the Markdown link works. Perhaps Wiki-style works better for writing apps, while Markdown style works better for HTML-rendering browser apps?

Anyway, this is just a question for someone brainier than I, with some free time on their hands, to gently explain the obvious to me.

Thank you all. I'm elated that I found this community. It's helping me finally formalize so many nebulous thoughts!

ctietze

I have a technical thing to add: in terms of links, Markdown is very extensible through pre-processors. That's how I used to write my links in notes: [text that's clickable][§201804062041]. You see that this is a reference-style link. If you convert the document to HTML or use Marked for a live preview, this document will just work:

[text that's clickable][§201804062041]

[§201804062041]: file:///path/to/the/file

Of course the linked note will not open in an editor but revealed in Finder. But it's a start.

Now adding the link reference definitions (the last line in the sample) would be a pain. You want the convention to Just Work™. That's where a preprocessor comes into play: a script that adds definitions for all the [§(.*)] (naive regular expression) and inserts the full path at the bottom of the document before you render it. A note archive app aware of this convention could include that feature out of the box, too. It's just being lazy with the links and having a script complete the Markdown file. The § is just sugar to make these note links recognizable both for you and the pre-processor. That's all vanilla Markdown, in the end. It's unlikely but possible you will do this manually.

But if that's the route you take, you can just as well write a pre-processor that converts [[...]] using a very similar mechanism.