Updating bookmarks when deleting links between documents

Scrivener Scrivener for macOS
,
1

Hello,

I posted on a very old thread from 2019 which seemed to correspond roughtly to what I was looking for, but perhaps that was not the best idea…

I would like to know if it is possible to update bookmarks, for example if I have deleted a section and I have not seen that there were links leading to it, is it possible to find broken links so as to redirect them?

Thank you

2

Hi.
If you deleted a binder document to which a link was pointing, clicking that link will still take you to that document, but in the trash.
So I guess you could use Find by formatting to cycle through all of your links, set the links to open in the other editor (so that it doesn’t take away your scrivening of the whole in editor 1) and see which ones need an update.

If there is a built in function to handle this, I either can’t recall or just don’t know.

. . . . . . . . .

Another way (if you have set the links to auto link back/bookmark documents) then you could simply have a look at the document bookmarks of the documents in your trash.

image

1 Like
3

Thank you very much for your help. I do empty the trash regularly, though, so I supose these links will not lead anywhere. I wonder if they are somehow marked as “broken” or if they just disappear from my <$hn> placemarkers.

I have just checked, and “Documents links and bookmarks create back-link bookmarks” is ticked.

Maybe I will just have to run a full search of <$hn> through a 400-page Scrivening and see what leads nowhere. This is going to take a while, as I tend to write quite often “mentioned in section <$hn>,” for example.

4

I fail to see how links and numbering-placeholders (<$hn>) are here related, but no, I don’t think there is anyway of getting an automated report on broken links.

You might be able to trick Scrivener into removing the broken links from a compile, but I won’t get into this. (One: I am not certain it would work. Two: it’d be complicated. Three: would it help in anyway? Probably not.)

I think in the future your best bet would be to not empty the trash.
(Or, if the size of the project is an issue, create yourself an extra level of trash. A folder near the bottom. “Docs kept just in case”. Or use it as a pre-trash. Move whatever you’d normally trash to this folder instead. And trash from it only what you are sure you want gone.)

You could also do and keep special backups from just before you empty the trash.

I think they just stop working.

Yep: image

1 Like
5

Have you actually tested that usage? I wouldn’t expect it to give the results you’re looking for in any case.

1 Like
6

Thank you for your suggestions. Yes, not emptying the trash would probably be a better idea in the future.

The reason the issue is related with placeholders is that I first write “section <$hn>,” then select the placeholder and create a link to the section in question by sliding it on the placeholder. This works really well and allows me to move sections around until the end. Actually, this is the only reason I have bookmarks in this project, I believe, apart from a few external bookmarks to other files in my computer.

Thanks! It might not be that long to run through my placeholders, actually. It will be very quick to see which ones do not lead anywhere, as in the image you have attached. These are normally the only ones I should worry about, as all the others should normally lead to the right place :slight_smile:

@kewms I think I have just answered :slight_smile:
Yes, it works really well when I compile. This is actually a GREAT feature, as far as I am concerned.

7

To described intended behaviour:

  • Bookmarks do get swept when you run the Empty Trash command. It’s efficient to do so, and helps keep the project tidy. There are some areas where items can vanish without triggering that behaviour. We have it on the list to look at, but one off them is if you merge several items together, that’s a way in which an item can be destroyed completely without going through the typical trash cycle. There may be some other edge cases as well, but by and large you shouldn’t see a gradual increase in broken bookmarks over time.
  • Hyperlinks are another matter. For performance reasons we can’t so easily trawl through the entire project’s data storage for each item that will be trashed. It’s on a list somewhere for consideration, but it would likely require some infrastructure to become feasible, because at the moment, we are talking about opening, reading and potentially writing to thousands of files just by emptying the trash.
1 Like
8

@AmberV
Perhaps what could be interesting would be to have a special document (special in the same way the research, trash and manuscript folders are special) that lists Binder’s content along with the links (their target doc) within each of those documents.
Not a document intended to be compiled, and that the user could (on demand only, nothing live) refresh from a button or menu command.

Something like :

Draft/Manuscript
In the begining
Part1 (Joe and Mary) — In the begining — Epilogue
Joe — Part1 (Joe and Mary) — That first day — Epilogue

. . . . .
“That first day” would be a document that is referenced to in a link, but that is no longer present in the project. (Could perhaps even mark documents still present in the trash a different way.)

Just an idea.

1 Like
9

I think if we were to come up with a better outcome for this particular matter, it would be something along those lines in intent but probably not form—something more like a project search function that highlights items with bad links and makes it easy to step through them, so they can be audited and corrected in the way each individual case might require. You’d still need an index for that, but this is not an impossible problem, and such an index would enable other potential capabilities as well, such as true back-link listing rather than spamming permanent bookmarks to simulate the idea.

So all around I think that’s a good route to go anyway, and thus an idea like this, that would reduce the RTF file scanning down to one, would not be necessary, and we could avoid any potential confusion with it.

2 Likes
10

Sounds good.
I didn’t understand anything from the last paragraph, but the project search thing sounds good.
:slight_smile:

1 Like
11

I am happy to read your message. I feel less lonely as I know I am not the only one who does not understand everything xD

@AmberV
Thank you for these explanations… and prospects. Scrivener is such an amazing tool already, it is rejoicing to know that it is still going to be improved! :slight_smile:

1 Like