A plea for Markdown Links (and other Link related bugs)

My obsidian journey has been quite enjoyable so far, but I’ve come across various problems with using links. The main selling points for me where the non-proprietary file formats (compared to cloud hosted apps) and the powerful linking support (compared to other markdown-capable editors). However, when you try to make use of both of these selling points at once, you’re left with notes that support neither :confused:

Okay, maybe I’m exaggerating a little, but I want to make a case for making markdown links first-class citizens. It feels like wiki link support comes first with markdown links coming second. Since the rest of the formatting syntax is based on markdown syntax (not wikitext syntax) and markdown-capable editors seem to be more readily available, I really hope to bring some attention and love to markdown links. It’s the most intuitive way to enjoy both key features of obsidian at once :slight_smile:

Also to comment on the help docs:

By default, due to its more compact format, Obsidian generates links using the Wikilink format.

With the introduction of Live Preview and link generation, it seems that syntax length no longer matters.

This is an overview of bugs reported for markdown links:

And more bugs reported for links in general:

There is so much potential here to make the links a more integrated part of the markdown experience while being able to have peace in knowing that you could always just open the vault in another markdown editor if needed. But to spark more interest and get some imagination flowing, let me share some thoughts on where all of this could go.

The Future Of Links

Alright, so imagine if we could put markdown links center-stage. How would it actually work? Well, I spent some time daydreaming about it. These ideas could be feature requests if they aren’t already, but for now I’d like to keep this post in the bugs category as I mainly want to bring attention to the bugs first.

Inserting a new link

The tricky part of links is that they consist of 2 components. I think using (shift-)tab controls could bring a lot of power here (which has been done before in plugins like Advanced Tables). So imagine you could type [] to generate an empty markdown link, put the cursor at the address section and open up the note auto-completion pop-over (alternative 1, alternative 2). From there you could select the note, optionally pressing # or ^ to select headers/blocks. It should also contain the current input as an “unresolved note” suggestion (related 1, related 2), which would follow path style preferences, follow default note location and auto insert .md at the end once selected. Perhaps there should be 2 “unresolved note” auto-completions depending on whether or not the user wants to make use of the path related corrections.

Once you press Enter (confim auto-complete) or Shift-Tab (ignore auto-complete), your cursor would jump to the alias section. There it would pre-fill the note file name, select it and provide another auto-completion pop-over for names, including file name and frontmatter aliases. This action would be the equivalent of pressing | in wiki links. From there, Tab could be pressed twice to jump out of the link markdown via the address section.

If a link to an unresolved note is clicked there is no need to adjust the link since the address was generated when the link was first written.

If text is selected while pressing [( it would automatically generate a markdown link with that text for both the alias and address (using [] would have collided with reference/footnote workflows). The address would automatically have .md on the end if it didn’t already, while the alias section would be stripped from trailing .md. It would also automatically select the address section for editing (since selected text is intended for the alias section in most cases).

Alternatively, pasting a URL would automatically wrap the selected text in a markdown link with the clipboard text as the address. Perhaps it could also automatically interpret and sanitize obsidian urls within the same Vault.

Editing a link

When using the arrow keys to enter the link markdown, it would automatically select whatever section is closest. During editing the auto-completion pop-overs would show up again. (Shift-)Tab can be used to switch (and select) between sections or to exit the link markdown area. When the link is unfocused (or the note is saved), the URLs would automatically be encoded.

Renaming or moving notes

There is also some room for discussion on when link aliases should be modified when notes are renamed or moved. I think the alias should only be updated if it’s the exact file name (without extension) or the full link address. The new name or new address is chosen based on the type of the original alias. There is never ambiguity between whether the alias was a file name or the full address previously, because the address always includes .md while the file name never does.

This bug describes that renaming is currently dependend on the address and that the alias sometimes changes into the full file path if it wasn’t before. Two behaviors I’d avoid.

Migrating and Converting

In order to adopt the new link style it’s important to have thoroughly tested vault-wide migration available. Also maintaining wiki-link code alongside could be troublesome, a solid migration plan could allow wiki-links to be phased out. That might be a hard pass when you read it now, but I do think that markdown links with excellent editor aid is the way to go.


As you can see, there is a decent amount of posts being created on the forums related to links, but they rarely get traction and there is no sense of a unified vision rolling out of it. I might not have the right answer, but I hope to bring some cohesion and at least trigger a conversation on the topic of links.

A note for mods: I understand this is not a conventional bug report, I hope you see value in this post and move it if needed instead of closing/removing it. :pray:

6 Likes

Hi.

Thanks for taking the time making this list. We already keep track of macro area of intervention internally and we prefer users to comment on each Feature Request/Bug Report to keep things atomic.

For your additional proposals that are not covered by already existing FRs/BRs, please open a new Feature Request and follow the FR template. One for each Feature Request, thanks.

1 Like

Another issue with Markdown links besides the length is that they may not work across devices because of differing paths (unless you use relative links, which have their own issues). Possibly Obsidian treats internal Markdown links differently to avoid that problem, but if so that behavior can’t be expected in other apps.

(I do think it’s good to support Markdown links well, but I’m a wikilink user myself so it doesn’t affect me personally.)

In most cases apps treat absolute URLs with the entire project/repo as root. See also the discussion about starting absolute paths with a /. Also all operating systems support forward slashes in file paths which is also currently already used in Obsidian, so that shouldn’t be a problem.

1 Like

I don’t agree with this statement. Some apps do, most app, I wouldn’t be so sure about that.