Improved Item Link expansion in markdown files

Hey,

When you paste an item link into markdown files, DEVONthink automatically converts them to links. For example, if I paste

x-devonthink-item://C9940DDE-CE89-4376-9FAF-42536730C220?page=3

it may become

[Ingarden, Roman 1973 - A priori Knowledge in Kant](x-devonthink-item://C9940DDE-CE89-4376-9FAF-42536730C220?page=3)

This is a nice feature, but I wished it would respect existing markdown links. What happens is that the existing text-part of the markdown link already in place, simply gets deleted and replaced.

My scenario is as follows: DEVONthink indexes all the markdown documents from Logseq, where I might collect references on a particular topic I am researching. If the references are formatted like this:

- [@ingarden1973, [42](x-devonthink-item://...)]
- [@ingarden1973, 64]
- [@ingarden1973, 195]
- [@ingarden1973, 203]

whenever DEVONthink, I assume, re-indexes the files, all the links get destroyed and I end up with this:

- [@ingarden1973, [Ingarden, Roman 1973 - A priori Knowledge in Kant ](x-devonthink-item://...]
- [@ingarden1973, Ingarden, Roman 1973 - A priori Knowledge in Kant]
- [@ingarden1973, Ingarden, Roman 1973 - A priori Knowledge in Kant]
- [@ingarden1973, Ingarden, Roman 1973 - A priori Knowledge in Kant]

Imagine there are hundreds of references, that’s hours of work to fix.

The desired result: Do not insert a markdown link if the item link is already wrapped in one.

Merci!

Did you create these links or DEVONthink? DEVONthink should actually escape certain characters when pasting links or dropping items:

[@ingarden1973, \[42\]](x-devonthink-item://...)

And then the preference to automatically update item links after renaming shouldn’t cause any issues.

Thanks for the swift reply!

No, what I usually do is, while reading a document, copy the page-link or selection-link and then create the markdown link in another editor, i.e. Logseq. Also, notice how in your example the entire string is a link, whereas I was using just the number to represent the link.

[@ingarden1973, [42](x-devonthink-item://...)] <!-- like this -->
[@ingarden1973, \[42\]](x-devonthink-item://...) <!-- rather than this --> 

Perhaps the extra enclosing square brackets cause the replacement, or rather cause the measures to prevent replacement to fail if they are already in place?

– Edit

To give you an idea of what it looks like from Logseq; every full title of the document you see in the image used to be a page number that has been replaced. Each link points to either a page-link, selection-link or annotation-link.

In that case disabling the preference should be sufficient to avoid this issue.

Indeed :smile: For now, that’s what I’m doing, but otherwise it’s a really useful feature. I was hoping to not lose it completely.