Have separate "Use Markdown links" options for wikilinks and image links

Have you searched for an existing request?

Yes. See “related feature requests”.

Use case or problem

I want to export my notes to my site, which accepts [[wikilinks]] but not ![[image_links]].

Indeed, if [[wikilinks]] are becoming more and more integrated in websites, it’s not the case for ![[image_links]].

Therefore, users may have a framework that accepts [[wikilinks]] but not [[image_links]].

Proposed solution

Unbundle the “Use Markdown links” option in the “Editor” menu.

I’d like to have separate options for wikilinks and image links.

[ ] Use Markdown links for wiki-style links : [[…]]
[ ] Use Markdown links for internal image links : ![[…]]

Current workaround (optional)

In my case, that forces me to modify image links (markdown) by hand, which is be quite cumbersome.

Related feature requests (optional)

There is :
https://forum.obsidian.md/t/autocomplete-for-links-images-using-standard-markdown-notation/ -> Autocomplete images and wikilinks links as markdown links. A comment explains partially what I need, by the way.


-> Convert internal links to wikilinks

Use standard MD links for images -> This is close, but does not mention the decoupling between wikilinks and image_links.

@matti told me that he asked for the same thing. Great, we can be friends now ! :smile:

9 Likes

My own Request is related to this :Setting link and image link styles independently

3 Likes

Thanks, I’ll update my request !

1 Like

Have you searched for an existing request?

Yes.

Use case or problem

  • DevonThink supports only standard image links, e.g. ![](foo.jpg)
  • DevonThink supports clickable WikiStyle links, e. g. [[bar]]

… but I can only set every kind of link (image and non-image) to standard or everything to obsidian. I can not set them independently.

Proposed solution

There should be two settings: One for “normal”/internal links and one for image links.

Current workaround (optional)

Use standard. But then links are only clickable (in DevonThink as in Obsidian) in the (Pre)View-Mode of the file.

4 Likes

I use GitJournal. It supports wiki links, but it only supports the markdown style of image links. Please separate the link format switch from the image link format.

3 Likes

Oh I would like to bump this. The ability to retain Wikiliks for markdown files, but using Markdown links for images (especially when pasting, and putting in those %20 in spaces), would make the notes more compatible with other markdown editors as well.

4 Likes

I just discovered that the default internal links for pasted images e.g.

![[Pasted image 20201106170215.png]]

will not display in basically any external markdown editor. What is the advantage of using these style of links vs “standard” markdown format of:

![](attach/Pasted%20image%2020201106170215.png)

Anyone got a good solution for converting existing internal links to standardized format (for images only…) ?

1 Like

A similar problem - I use GitJournal and have to manually fix markdown links to notes in wiki links. Besides GitJournal, most editors on iOS/Android do not support the wiki style of image links and support the wiki style for links to notes. Easy-to-fix stuff that significantly expands the ability to use the knowledge base on mobile devices.

2 Likes

A temporary solution to the problem is to use the Wikilinks to MDLinks plugin (available in community plugins). You can use it to switch between wiki and markdown links to notes or images using a keyboard shortcut.
However, I still hope that the developers will separate the option for images and links to notes in the program without using third-party plugins.

4 Likes

Yes, much need this!

Using ![](image.png) and ![](<image name with space.png>) for normal image and other files, and using ![[Note Ref]] for internal note links.

Waiting for that!

+1 please

1 Like

I would also like to have separate options for internal vs. external links. For internal links, Wikilinks are less verbose and nicer. For external links, Markdown links are not only more interoperable with other apps but they’re also easier to read (the text should come first, not the less important URL).