Count transclusions as links (and therefore backlinks) in extractLinks, added test

[ConorLPBoyle]

I wanted backlinks in my custom ViewTemplate to also reflect transclusions as incoming links, so I changed my wiki.js to do that a while ago. I haven't observed any unwanted behavior after making this change, so I'd like to propose it be added to core tw5.

This change makes the links and backlinks operators count transclusions as links.

The change passes /bin/test.cmd. I've also added an extra test to amend the spec.

[sobjornstad]

@diego898 pointed me here from a thread I just posted in the forum asking about the possibility of a filter operator or some other mechanism to find tiddlers that are transcluded in a tiddler, or tiddlers that transclude a tiddler.

I really like the idea of this PR, as evidenced by the fact that I just asked about almost the same thing, but I dislike the specific implementation where links and transclusions are lumped under the “link” umbrella and can't be differentiated. Semantically, transclusions are not links. They both allow content to be referenced in multiple places, but in very different ways, and many people use them in very different ways. My ideal would be implement this functionality, but in a way that allows for true links and transclusions to be separated, perhaps with a separate filter operator or a suffix.

As an example of a case where I'd like to keep them separate, I'm currently working on a small textbook where I keep each exercise, and some small tips and references, as individual tiddlers. Sometimes I'd like to be able to include one of these tiddlers in multiple places. It would be useful to be able to retrieve a list of those places, but that list shouldn't include places where the exercise was just referred to by name (via a link).

Similarly, if I transclude a template that just displays some information about the current tiddler, or a verbatim tiddler that puts a notice at the top of the tiddler, I don't really want to see that as an outgoing “link” within my tiddler.

I could see an argument for changing the default behavior of links[] and backlinks[] so long as there was still a way to limit it to only true links should one so desire, though there might be some concern for backwards compatibility.

[Jermolene]

Hi @ConorLPBoyle @sobjornstad thanks for this. I agree with @sobjornstad that ideally we wouldn't lump links and transclusions together. Instead, perhaps we might introduce a suffix for the existing links and backlinks operators that allows the type of link to be specified: links:transclusions[] with the default being links:navigation[].

Behind the scenes, the system uses a couple of approaches the speed things up:

• It caches the outgoing links for a tiddler in the wiki.getTiddlerLinks() method
• We've recently added an indexer for speeding up backlinks

We'll have to integrate with the existing backlinks indexer, and we should also add a wiki.getTiddlerTransclusions() method that caches the outgoing transclusions for a tiddler.

I'm afraid that's all a bit more work, but I and other community members will be happy to help.

[pmario]

I think it should be separated functions!

I made a plugin that works with alias-links ... So to be consistent I would need to add links:aliases .. But for that I would probably need to overwrite parts of the core wiki-methods, which can cause incompatibilities between my plugin and the core. ..

Which it already did 2 times. ... So that's why I think new functions, which go into indexing and backlinking should be separated.

[pmario]

The wiki-methods for links are: wiki.getTiddlerLinks() and wiki.getTiddlerBacklinks()

The names for transclusions may be: wiki.getTiddlerTransclusionLinks() and wiki.getTiddlerTransclusionBacklinks() ... Which I think are a bit "bulky"

[pmario]

@Jermolene ... We have "missing titles" and "orphan tiddlers" ... Do we go as far as "missing transclusions" and "orphan transclusions"?

[pmario]

It would be nice, if exports.extractLinks = function(parseTreeRoot) { would be a wiki-method, that allows authors to extend, without the need to overwrite the core function. .. May be a "extract-links hook" of a similar mechanism

[Jermolene]

Hi @pmario

Do we go as far as "missing transclusions" and "orphan transclusions"?

I can see situations where missing transclusions might be useful, but harder to see orphan transclusions as being useful.

[ConorLPBoyle]

Well, seeing as this started the ball rolling, might as well implement #847 instead.

I'd be partial to transclusions[] and backsclusions[] over suffixing links[], but I can see how that would avoid unnecessarily duplicating code.

The only non-duplicated functionality required is handling template transclusions.