Excellent, thank you.
Another tip for people who can’t get it to work:it didn’t work for me after I turned on the features in the WikiLinks settings panel until I force-quit the DTTG app and restarted it.
1 Like
Wow it’s awesome!
Small possible bug. When use [[ method and create more than one wiki link, the latter link is displayed as [[ style but the former just a link in blue font without the [[. And if a [[ is used and title of the linked document is for example capitalised, but text entered after [[ is not (and typed as lower case), subsequent letter in the link created are still capitalised, but the caps are not carried over from the actual title for the part that was typed after the [[ (I am not sure how clear that is but let me know if need to elaborate).
But this is seriously good, it’s such a good piece of work.
A screen capture would be helpful here.
But this is seriously good, it’s such a good piece of work.
And 
agreed! 
Hi Bluefrog,
Here’s that screen shot.
So I have created 3 documents, Doc 1, Doc 2 and Doc 3 and creating wiki links to Doc 2 and Doc 3 in Doc 1.
The first link is to “Doc 2” and is shown as a simple blue link without the square brackets, the second link is to “Doc 3” and is shown as [[doc 3]]. Both links are created using [[…]] method.
A blue link is also automatically created by the title (which is the same as the file name) but in this case the link refers to to the same document in which it is embedded so is redundant.
So I was only asking if this is intended.
But loving it.
I have intermittently had the same issue.
You have Names and Aliases enabled, correct?
Development would have to assess the “redundancy”.
If you add a new line after the [[doc3]] it will remove the brackets in the rendered markdown. I have added a fix for this for the next update.
Yes that’t right BlueFrog, all options are checked but probably will go with just the [[ syntax.
Awesome thanks so much for the great product.
It’s up to the individual but I personally think using one of the options is less confusing than using several. 
Sorry to bother you again. I’ve been using the WikiLinks feature for a week now and I notice to other potential bugs:
1. It happens, that DTTG “forgets” the WikiLinks. I.e., previously correctly detected Names and Aliases WikiLinks don’t show up after some time unless you quit and reopen DTTG:
Nothing has been changed between the two screenshots except that I restarted DTTG in order to make the WikiLinks detection work again.
2. In long texts with WikiLinks, the editing becomes very laggy. I made some tests and found that the lag starts at around 5000 words or 50,000 signs. When I remove/deactivate all WikiLinks in the same text, the editing works fine again. I tried to take some screen recordings, but I don’t know if you can recognize the lag therein. Therefore for reproducibility: the text with 5000 words and 50,000 signs contained 1.000 WikiLinks.
Please let me know if you need further info.
1 Like
-
I’ll see if I can reproduce this here. Any suggestion on how long it took before they vanished and if you were busy in other applications and returned to DEVONthink To Go?
-
Not saying it shouldn’t be supported but this is a bit of a stacked deck, with 5000+ words and 100’s of redundant WikiLinks.
PS: what are signs?
PPS: Have you used DEVONthink’s Lorem Generator script?
1 Like
- So far I couldn’t find out, after which time the “forgetting“ begins or could trigger it. I have an iPhone 13 pro, memory or disk space should be no problem. I also haven’t done any “heavy“ stuff before the “forgetting“ begins. However, I additionally noticed today, that the “forgetting“ seems not to occur in each and every note and not for each and every WikiLink: there are some notes, that still have WikiLinks correctly recognized and active, but by far not for all actually available WikiLinks in that note.
- I noticed the lag in my longer notes. In order to reproduce and to trigger the occurrence of the lag, I tried to “standardize“ a test note with repetitive blocks of fixed words and fixed number of signs. So I was able to see around which threshold of word and character count the lagging would start. With “signs“ I mean a single character or letter. And yes, fully correct: having 1000 times the same WikiLink in a note is redundant and is not the usual case in my notes. For this test I included only one unique WikiLink word, which was repeated several times in the standardized text blocks. In my usual, longer notes, where the editing lag occurs, I have many different WikiLinks.
Another add-on from today:
- I repeated my test, now with a text corpus that consisted of only one WikiLink, that has been repeated a 1000 times (hence, the word count was 1000 and the character count was ~6100). No other additional text was added this time. As a result: there was no lag. So far it seems to me, that a combination of a long text corpus with many WikiLinks causes the lag
Another addition to 2:
2.1. I further refined my initial test with 5,000 words/50,0000 characters. Now, I included 20 unique WikiLinks, each repeated 100 times, and activated them incrementally in order to see, when the lagging would start. At around 450-500 WikiLinks (=9-10% of the entire text (regarding the word count)), the lagging becomes noticeable.
2.2. Same as 2.1, but keeping only 8 unique WikiLinks active (8x100=400 WikiLinks = ~8% of the entire text/words). Now, I added some Markdown text formatting, namely text highlighting (“{== … ==}”) and citation blocks (“> …”), and this increased the lagging dramatically. I.e., in 2.1 with 8% WikiLinks, there was no lagging, but the added formatting triggered it now already at this threshold. Therefore, now I think, the lagging is caused by a combination of a long text corpus, some percentage of Wikilinks and Markdown formatting commands, which is more comparable to the actual notes, where I first noticed the lagging.
Some more feedback with small bug, i am now set up with just the automatic recognition toggled to on, plus the square brackets. All other settings are off. If for example I create a link and use a lower case, instead of upper case (and the document is named for example with upper case) then it autocompletes and inserts a link with partly with lower case. This wiki link is active in the source mode, but not recognised in the preview mode.
So for example let’s say my target document is named “ABC”. So I type lower case “[[ab” into into the document where i am trying to link to “ABC.” I see “ABC” as an option. I select it, and [[abC]] is created.
This link is recognised in the source mode, but not the preview mode where it simply shows [[abC]] but is not actually rendered as a recognised blue link.
Furthermore, if I press on the link in source mode, it creates a new linked document using the template rather than linking to the correct document.
Thanks for the clear description of the tests and results, we will look into the issues you highlighted.
1 Like
Thanks for feedback, I will add a fix for the next update
You guys are amazing! With the today’s update to DTTG 3.7.2, the lagging has vanished! Thank you very much 
4 Likes