#1

Use case or problem

Please reconsider the need for markdown links to be urlencoded. The readability of markdown links is severely hindered by this requirement and it is not obvious why Obsidian would need to urlencode links in the first place. Removing this requirement would not only improve readability, it would also improve interoperability, since other markdown software that existed prior to Obsidian often doesn’t work with urlencoded links. Devonthink is an example.

EDIT: DevonThink is able to use urlencoded links if the link target has a proper extension.

Example:

[2020-02-10 - FacileThings](2020-02-10%20-%20facilethings.md)

is harder to read and less platform independent than

[2020-02-10 - FacileThings](2020-02-10 - FacileThings.md)

Proposed solution

Remove the requirement for urlencoded markdown links, but allow them to be urlencoded for backwards compatibility. New markdown links should be created using not-urlencoded links.

Current workaround (optional)

None! Using the wiki links feature is even less interoperable.

Related feature requests (optional)

None.

1 Like
Updating Internal Links: Removes File Extension When Using Markdown Links
#2

@matti, you can actually have links with spaces in them if you include them in angle brackets, like this:

 [2020-02-10 - FacileThings](<2020-02-10 - FacileThings.md>)

I believe this is even CommonMark standard. Without the angle brackets, the document would not follow the CommonMark or normal Markdown standard and therefore not be usable with other Markdown editors and tools.

However, I think Obsidian should provide some support for adding either angle brackets or urlencoding automatically. The angle bracket syntax has the advantage that it is more readable, the urlencoding has the advantage that is is even more compatible. So it would be best to make this configurable.

This should also both be supported by the “paste URL into selection” plugin. I already created an issue for this.

2 Likes
#3

Sadly the CommonMark spec is not compatible with Multimarkdown in this case (it seems), which is why your proposed solution will not help to make it work in software that adheres to the latter, like e. g. DevonThink. DT doesn’t understand links like [2020-02-10 - FacileThings](<2020-02-10 - FacileThings.md>).

So I guess we would need a compatibility mode? Or an option to use Multimarkdown instead of CommonMark as the Markdown standard to use?

#4

Right. Regarding the automatic conversion, it should be made configurable whether to urlencode or add angle brackets because it depends on your needs for compatibility.

But I think it’s always ok to interpret the angle brackets as unescaped link since this would not be a valid link otherwise anyway. So maybe this could be added as a feature in DevonThink as well.

#5

Yes. Agreed. May we could add an mmd compatibility option that does what I have proposed originally?

It might be worth a try. Although I am not sure that mmd (which doesn’t seem to have a human readable spec would allow for such a thing…)

#6

Ugh. It turns out urlencoded Links actually work in DT. What doesn’t work is leaving out the extension:

  • This works: [2020-02-10 - FacileThings](2020-02-10%20-%20facilethings.md)
  • This does not: [2020-02-10 - FacileThings](2020-02-10%20-%20facilethings)

This seems to be related to this bug: Updating Internal Links: Removes File Extension When Using Markdown Links

Nonetheless, the readability would still be improved.

Apologies for the mess.

#7

We urlencode internal links automatically.

#8

This is unlikely to happen for compatability reasons. I am going to archive this feature request. You can open a feature request for adding the option to use <> in place of urlencoded.

1 Like
#9

@WhiteNoise Thanks for the (as always) swift answer. Even though I think it would be a great option to have, I appreciate knowing what to expect.

@Cito Since putting note links into angle brackets is not immediately useful to me, I am not going to open a new feature request. I just thought I’ll let you know, if you want to open one.