I select some text in file A and create a link from there to file X. When I go to file X and look in it’s Document Bookmarks, I see that it’s automatically back-linked to A (as documented; and this is a feature that I like).
Then I copy (on mac: Option+Drag) file A to another folder, creating file A-1. File A-1 contains a link to X, but it doesn’t show up in X’s Document Bookmarks (unless I manually add it).
I would love it if it did . If it did, then I could rely on those backlinks to help me chase down implications of later changes.
Is there a better way to accomplish what I’m looking for? Or is this a feature request?
The backlink is created at the same time as the original link. Since duplicating the file doesn’t create a “new” link, it doesn’t trigger creation of the backlink.
(Whether or not it should do so is another question. Arguably it shouldn’t, because repeated such operations could create a lot of clutter. Which of these five links to similarly named files is important? We’ll take it under advisement.)
Could you elaborate on what you’re trying to accomplish? If you’re duplicating file A before editing it, would making a Snapshot serve the same purpose?
If I split a document, backlinks are not update and therefore still link to the shortened original document even if the link is now in the new split document.
If a link is removed, the backlink to the document remains.
Not the end of the world, but sometimes when I reorganise notes I change the scope of a note and want to make sure that everything that links to it is still fitting (and link to other notes if I moved the relevant parts elsewhere). “Wrong” backlinks make that difficult sometimes.
So in case the backlink mechanism gets an update somewhen, please look into those two issues as well.
Yes, I think it is important to distinguish what Scrivener does from the concept of a “back-link”, as a popular concept of the automated feature many software tools provide. It certainly is not that. It is a static and editable record of cases where something was actively linked. Copying and pasting links, splitting, duplicating, none of these things qualify for that action.
If you are aware of that design point, it is easy enough to trigger the condition if that is what you want, on the new item.
The advantage of this approach is that one key word from above, editable. You have control over the list, rather than it being full of chaff that may be of no importance to you, just because the machine found references.
This is not a new topic however, and here are a few existing threads and thoughts on these concepts:
What I would like to do is connect places where a change in one of those places would need to be propagated (Checkov’s gun was described as an AK-47 in lots of places, but then I realize that’s anachronistic and need to go update them all; but usually my use cases are much less easily-searchable).
And sometimes it’s just mighty convenient to take some text that’s been linked (especially in an inline Annotation, where it’s less likely to be subject to local seach-unfriendly description variations) and copy-n-paste that linked text into another place where I also want a link (instead of re-selecting + re-creating a new link).
In the past, I would just make a few empty lines of inline annotation at the beginning of the target doc, then when I link to it I’ll create a link, click the link to open the target doc, drag the current doc’s file from the Binder into that annotation space at the top; and bingo: I’ve got links in the target doc that point me to everywhere that’s connected to this.
That’s manual, and a bit ugly, but honestly it works wonderfully and makes me happy. That functionality is one of the things that I love.
I recently started just depending on the automatically created backlinks in the Document Bookmarks of the target doc … but then discovered that they’re not all always there
On the other hand; I can manually update the document bookmarks just like I was using that Annotation block – not yet sure which method I’ll adopt going forward (will experiment).
@AmberV Thanks for the good links. Your thinking there is very similar to mine, and the discussion context there is helpful - Thanks!
I wonder how hard it would be to leave the document bookmarks as-is and add another inspector box under it which is just the backlinks? That box could scan the binder for links to the current doc whenever the box is opened (maybe use the same logic as the dynamic search saved collections? – or maybe even a better solution is to add the ability to do a search for links to a specific document and save that as a saved collection… that would work wonderfully on my end (except that it would add another ~20 saved collections to my already too large list of typically >20 – hmmm …) ).
For the concept of edit tracking itself, you might be interested in this post, which describes how I record larger scale edits, documenting them, so that future changes can be made much more efficiently. I’ve found having these kinds of “nexus” notes that describe an edit will often be useful for other adjacent edits as well, too.
It is something one does manually, yes, but I’ve often found that isn’t a bad thing in and of itself, and often for the same reasons Bookmarks in general can be more focused on what matters. Sometimes an edit in relation to a larger group of edits really isn’t worth documenting. Maybe what I did was remove mention of that thing so that I would no longer have to maintain that section if something changed about it. Why clog the list up with something like that, when the referenced binder item no longer has anything to do with the topic?
I wonder how hard it would be to leave the document bookmarks as-is and add another inspector box under it which is just the backlinks?
That is certainly something that I do have notes on for consideration in the future, and in particular, being able to easily “promote” such automatically generated references to Bookmarks so that they gain the various advantages I listed in one of those posts. There definitely are challenges with that idea, and in a such a way that it would require a much more comprehensive overhaul of the internals of a project, for it to be something we could just slap into a minor release. So it’s not off the table, but it’s definitely not something coming any time soon.
. If it did, then I could rely on those backlinks to help me chase down implications of later changes.