-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Count transclusions as links (and therefore backlinks) in extractLinks, added test #4766
Conversation
@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 |
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 Behind the scenes, the system uses a couple of approaches the speed things up:
We'll have to integrate with the existing backlinks indexer, and we should also add a I'm afraid that's all a bit more work, but I and other community members will be happy to help. |
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 Which it already did 2 times. ... So that's why I think new functions, which go into indexing and backlinking should be separated. |
The wiki-methods for links are: The names for transclusions may be: |
@Jermolene ... We have "missing titles" and "orphan tiddlers" ... Do we go as far as "missing transclusions" and "orphan transclusions"? |
It would be nice, if |
Hi @pmario
I can see situations where missing transclusions might be useful, but harder to see orphan transclusions as being useful. |
Well, seeing as this started the ball rolling, might as well implement #847 instead. I'd be partial to The only non-duplicated functionality required is handling template transclusions. |
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.