Support real Markdown links between notes

Feature archive
20

@WhiteNoise you are already very close to providing the functionality that is needed. Consider that in order to provide the WikiLinks, Obsidian now does this:

Creating WikiLinks Internal Links

  1. user types a trigger ([[) which activates the system
  2. system offers user with a dropdown to choose from internal files, from which it will derive the link path
  3. system allows the user to extend the path with an internal document link, by watching for another trigger ("#"). If trigger is used, show possible internal headings, adding link to the path.
  4. last of all, system allows the user to define the link text, by watching for another trigger ("|"). If the trigger is used, then any text that follows will be used as the clickable text for the link.
  5. once everything is entered, Obsidian automatically creates and enters the WikiLink

In order to create an internal link using standard markdown, however, the only help the user needs is in entering the file path - as the user will manually enter the link text anyway. So, all we need is a shortcut help for adding internal file paths., in the standard syntax. Here is a possible workflow:

Creating an Internal Link with Standard Markdown

  1. user types in the link text (e.g., [my link]() or link reference (e.g., [link]:) stopping just before a path needs to be entered.
  2. The user types in a trigger - something like “((”, or “\\”, or even “[[[”,
  3. Obsidian shows a dropdown menu allowing user to choose files - just like it does now for WikiLinks
  4. Once the file (and optionally the heading) have been selected, Obsidian outputs the path - in standard format (so a file titled “my file.md” would be output as “my%20file.md” automatically).

This makes Obsidian super helpful also in building standard markdown links. Obsidian would still continue to make sure, that if the user decides to change the filename, such paths would be updated automatically, too (as it already does now).

Longevity vs Convenience

Most users are going to be very thankful that Obsidian provides such great features, which go beyond what is supported by the standard markdown syntax - or even by MultiMarkdown - such as WikiLinks, links to headers, and file embeds. These features are, indeed, extremely useful and convenient.

There are many users that are finding Obsidian when looking for a good Zettelkasten app. A key principle of Zettelkasten is to strive for longevity in our notes, and this is why many “Zettelkasten pro users” advocate using the simplest tools we can find - like text files, and nothing more than standard markdown for text structuring. There are, indeed, a myriad of other ways to keep our notes, which would indeed be much more helpful than just plain text - e.g., rich text, or full-blown HTML, .docx or even proprietary file formats offered by other apps. But from the Zettelkastener perspective, all these formats are ‘a risk’ of sorts, because we don’t know how much they will change (or whether they will even exist) 10 or 20 years from now.

So, while it’s awesome that Obsidian offers great ‘extended’ features, the most important feature of all, for a Zettelkastener, is longevity of their notes. And that means full support to the standard markdown syntax, as first-class citizen, and not as an optional afterthought. As soon as the app starts encouraging users to adopt non-standard syntax, it’s encouraging dependency and vendor lock-in.

I believe this is not the intention of Obsidian, because you guys go through great lengths to show users that one of your core values is that “the user should own their own data”. But what you might not realise, is that by encouraging non-standard syntax as a primary feature of your system, you are actually encouraging users to lock-in, and going against your own principle.

Non-Standard Syntax for Basic Features vs Add-On Extras

You are right in stating that markdown is limited - it is so by design. It is intended as a human-readable format, meant to be understood even if not parsed at all. Its intention is to provide essential structuring (h1-h6, lists, quotes, images), highlighting (bold, code) and a way to provide hyperlinking in plain text documents. It is reasonable for any user to expect that a program that ‘supports markdown’ would support these basic features well, and work with them in a reliable way, and with very little surprises.

If an app offers extended features that go beyond the basic markdown, those features will necessarily require their own syntax. By using them, the user understands that they are choosing to lock themselves into an app, and that specific feature set. If my notes absolutely NEED tables, I know that I’ll need to use multimarkdown syntax - and I’m going to be locked-in to apps that support it. If I cannot live without embeds, I’ll use Obsidian’s ‘embed’ syntax - and I’m willingly and happily locking myself into it.

Using proprietary syntax for ‘extended’, non-standard features is expected - and the user does it at their own peril. This is significantly different to encouraging the user to use non-standard syntax for basic markdown features, such as images and links. This is encouraging lock-in - and simply not necessary.

IMMHO, an app that has the motto “the user should own their own data” as its core, should encourage users to avoid lock-in, by encouraging the use of standard syntax whenever possible. I’m pretty sure that this is still Obsidian’s intention, but in the effort of being ‘as helpful as possible’ to the user, perhaps this principle is being forgotten - or, at least, ‘diluted’…

7 Likes
21

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.

1 Like
22

@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.

4 Likes
23

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.

5 Likes
24

@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
  • assume it’s an external link.
25

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).

2 Likes
26

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)

4 Likes
29

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.

5 Likes
30

Interesting point you make.

[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?

1 Like
31

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.

1 Like
32

Added in 0.8.5: Obsidian Release v0.8.5 (Insider build)

4 Likes
33

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:

  1. I want all my notes and links as future-proof and app-independent as possible;
  2. 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)?

34

Wiki-links are faster and easier.

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.

1 Like
35

After thinking about this subject, dealing with bug reports, etc. I’ll give my argumets for wiki-style links.

Negatives of Markdown links:

  1. They are way more move verbose, and you should use %20 or <> to handle whitespaces.
  2. 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)
  3. There is no spec for linking to header (but maybe there will be one?)
  4. 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.

5 Likes
36

@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.
37

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).

2 Likes
38

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.

39

@Dor, thanks for that detailed reply - that obviously makes a lot of sense!

41

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.

1 Like
42

you can use relative path in the settings

1 Like