Improved Item Link expansion in markdown files


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


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.


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.