I recently added backlinks to my wiki following the advice given here. Meaning that I’m using the following code with a $:/tags/ViewTemplatetag.
I noticed that this works, as long as the links to my tiddlers are created using conventional [[Linking]] but not is I use something like $list or {{{ [tag[List]] }}}
I’ve grown accustomed to using especially the latter synatx so i’m wondering if there is something I could do to adjust this backlink code to make it support generated lists.
As a rule if the tiddler is not “mentioned” (Eg [[tiddlername]]) in a particular tiddler, it does not become a backlink when only because it is listed as a result of the $list macro. There are ways to search “rendered” tiddlers, that is you wikify the text field before searching, but this is not very efficient, and since a given tiddler may be listed in many different ways, it could produce a lot of unwanted results.
keep in mind, depending on the filter used a given tiddler may, or may not, be listed if any one of the “variables” in a filter change, eg add remove a tag.
The same filter may be used in multiple tiddlers giving the same result, so in someways treating items “as listed buy a list widget” as “backlinks” is not what backlinks mean.
I am confident you may find another way to arrange your data which helps you discover the same thing.
Remember to look in the Info Button, where backlinks and references are listed.
You may add a step so if you want a backlink to a tiddler you make sure you add a link to it, not just because it is a member of a list.
If you want to ensure a backlink exists, but the link is not displayed in a tiddler you can do this ;
You could add a feature to your listing to allow you to select any, or all items and add it/them to a list field, then you will see these in the listed tab of the info panel, and you can add not just backlinks but listed items ie instead of a filter of [all[current]backlinks[]] use a filter of [all[current]backlinks[]] [all[current]listed[]] +[sort[]] in your view template.
To identify backlinks, the TW core needs to run the [[whole tiddler content]] through the first parsing step, where some information is created that this syntax links to a tiddler. We call this the “parse tree”.
So to calculate backlinks[] the TW core has to create a backlink-index by running every tiddler text through this first parsing step, if a special backlink is requested by the rendering mechanism.
If you use eg: <<list-links filter="[tag[something]]">> this fist parsing step doesn’t crate any information about the resulting list. It only creates info, that a filter [tag[something]] is used with the list-links macro. But this info isn’t worth too much, since filters are used all over the places for many different things and user defined macros can have any name. …
So it’s not possible to create a general algorithm that reveals the resulting list, except a full rendering of the HTML output and analysing this output for tiddler links. … So instead of 1 CPU heavy calculation, 4 heavy calculations would have to be done.
It’s needed to apply the first 2 steps from the rendering algorithm. Creating the parse-tree → create the widget-tree → analyse the widget-tree for backlinks or other stuff that may be interesting. … So it’s 3 heavy calculations and not 4 as I wrote above.
So in the end it’s a compromise in favour of performance.
Edit: After some more investigation I did change a paragraph above.
This has come up many times before, and I’ve always given the same answer as @pmario: that performance would be a concern. However, I’ve never gone as far as experimenting to quantify the performance hit.
I’ve now done a very quick proof of concept, and as it turns out, it’s quite usable:
It needs some more work, but on the basis of the initial results I think we can be confident that this feature will be viable for the core.