Embedded local media with square brackets don't work in edit mode

search

you are being told not use square brackets in files that you want to link.

What do you mean, “told not to use”?
Files with square brackets work in preview but not in edit mode.

when you try to name a note or file with square brackets or other characters a popup will warn you that it will affect linking. As you can see, it is affecting linking.

I don’t get any error messages when drag and dropping.
The copying of the file into the vault works, preview mode too.

This shouldn’t be allowed with drag and drop either, or there should be some feedback after copying a file that won’t work in edit mode.

thanks we should add warning there too.

This is still broken, but not for any reason that I can see. Not from a design or implementation perspective.

Fundamentally you have a question: is some[filename] or some[filename]with.this.extension.md a valid filename on operating systems or not?

Should Obsidian support valid filenames?

If it’s a valid filename, then it can be edited and opened. And Obsidian can edit and open the files.

But… it’s doing the wrong thing here.

  1. Filenames can contain brackets.
  2. There are non-ambiguous ways to reference those files.
  3. You can make Obsidian do the right thing in weird ways.

I’ve attached a directory that you can drop into your Obsidian vault:
linkbugs.zip (6.2 KB)

It contains several perfectly valid filenames that Obsidian believes it can’t link to. But in the simplest example I can think of create two files:

touch linky.md
touch this[file].md

And then within linky:

This has a link over [here](this[file].md)

Obsidian actually renders this correctly, detects the link, and if you click on the link it will correctly take you to the file.

It looks like square brackets are verboten in official MediaWiki links, as are %5B %5D (and other % friends) but I’m not sure that there’s any great reason to prevent that within Obsidian. It would be relatively easy to detect [[ and then the last matching ]] on that line and % encode everything within the brackets. As it is Obsidian will handle a opening brackets just fine: [[this is [[[[[[ some stupid file ]] will correctly interpret a file with a whole lot of opening brackets. Heck, even something as silly as [[this is [[[[[[ some stupid file] that] may have ] some others] ]] will correctly work.

Honestly it looks like the only required fix here is to change from eager closing of the MediaWiki tag, that is:

Instead of

[[this [is [[not]]] actually closed yet]]

being parsed as

this [is [[not
] actually closed yet]]

it should be

this [is [[not]]] actually closed yet