Erratic handling of malformed Markdown links

Bug reports
1

Steps to reproduce

  1. Create new vault. Add three notes named a.md, cats.md and eats mice.md. Add these lines to the first note:

    a

![cats](cats)

likes to

![eat](<eat mices.md>)

  2. Rename file cats.md to cat.md. Let Obsidian update the link in a.md

  3. Rename file eat mices.md to eat mice.md. Let Obsidian update the link in a.md

video

Expected results vs. actual results

  1. I expected an error message for the cat in reading view because the link was malformed. Instead it was rendered as if it were valid.
  2. When renaming cats.md I expected the malformed link ![cats](cats) being updated to ![cats](cat.md) not ![cat](cat.md). Why was the part in the square brackets changed?
  3. When renaming eats mices.md I expected the link ![eat](<eat mices.md>) to be updated to ![eat](<eat mice.md>) or ![eat](eat%20mice.md) instead of adding a title and having an unrenderable link ![eat](eat%20mice.md mices.md>).

Environment

SYSTEM INFO:
Obsidian version: v1.6.7
Installer version: v1.6.5
Operating system: Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 23.5.0
Login status: logged in
Catalyst license: supporter
Insider build toggle: on
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none

Additional info

Why malformed? Iā€™m referring to CommonMark Spec 0.31.2:

A link destination consists of either

  • a sequence of zero or more characters between an opening < and a closing > that contains no line endings or unescaped < or > characters, or
  • a nonempty sequence of characters that does not start with <, does not include ASCII control characters or space character, and includes parentheses only if (ā€¦)

An inline link consists of a link text followed immediately by a left parenthesis (, an optional link destination, an optional link title, and a right parenthesis ). These four components may be separated by spaces, tabs, and up to one line ending. If both link destination and link title are present, they must be separated by spaces, tabs, and up to one line ending.

Example 483 shows an inline link without title:

[link](/uri)

It is resolved as

<p><a href="/uri">link</a></p>

Expected behavior in Obsidian: the link [cats](cats) should resolve to <a href="cats">cats</a> instead of <a href="cats.md">cats</a>, because this is not a wikilink, where the file ending is omitted. The link should prompt an error message, because such a file does not exist.

Another expected behavior in Obsidian: updating the link destination should not change the link text.

The destination can only contain spaces if it is enclosed in pointy brackets: (ā€¦) Example 489

[link](</my uri>)

Expected behavior in Obsidian is a borderline case. ![eat](<eat mices.md>) should link to eat mices.md, if it is in the same directory as the linking file. So in the example above it makes sense to render the file.

However, if the linked file is moved to a different directory I expect it not be rendered, because it resolved to a <href> that does not address the correct directory.

Titles must be separated from the link using spaces, tabs, and up to one line ending. (ā€¦) Example 507:

[link](/url "title")

Expected behavior in Obsidian is that the pointy brackets are respected, when renaming the file. There was no title before the rename, so why add a title?

Edit: Add reference to CommonMark specs

1 Like