Combined documents and links

I have not found this on the forum. You see, I use links to documents a lot in my projects. Lately I’ve been also using the Documents > Divide and Documents > Combine functions, the issue is that they generate some strange(?) behaviour when I use them with links.
When I split a document, which has a link to it in another document, into two, the link now only refers to the first part (of the two that I have now divided). That’s fine, I think, it doesn’t cause me any problems.
However, when I combine two documents and both have a link, one of the old links dies, leaving only the first one to refer to the now combined documents. In the links I had for the second combined document, I only get something like ‘scrivlnk://…’ and a bunch of numbers and letters (like when a linked document is deleted, which I guess I sort of have). This ‘missing link’ doesn’t direct to anywhere.
Would it be possible that, when I combine two documents, the links for both documents are also joined for the references I already have included?
So far I’ve had to change them one by one by hand, and I have a lot of them, so you can imagine it’s very time consuming :sweat:. I don’t know to what extent this is possible in programming (because I have no idea), but I wanted to point it out since I haven’t found any discussion about this in the forum (or maybe I didn’t search enough).
Anyway, thanks for your time and have a nice day :heart:

1 Like

Meanwhile the solution, I think, would be to not actually (re)merge the documents, but rather nest the second inside the first, and display them as a scrivening when needed – which can be set to look the very same way as if they were actually merged as one, beside for the line numbering. (?)

You’d also preserve more accurate links.
I don’t know what it is worth at compile, though.

That’s the name the file had on your hard drive before being swallowed.


Just as a general note: this isn’t done (nor is it done when emptying the trash on items that have been linked to) mainly because there isn’t a good clear cut desirable outcome. You’ve described a case where one specific outcome would be beneficial for how you work, but for others that might not be a good result.

Sometimes an error or a broken condition like a link that no longer works, is a more useful result than one that effectively makes the problem go away or become invisible. Having an error that we can find gives us a chance to resolve the problem in a creative fashion. Maybe in realising we had dozens of items cross-referenced to a specific thing we can realise that destroying that thing and dumping its text into another might not have been the best decision, for example.

There is also something to be said for performance. It depends on the size of the project of course, but if links were always “fixed” when merging it would mean that some people would have to wait minutes after every single merge even if they didn’t use links, because there is no way for the software to know if zero or 5,000 links exist to a thing, without going through every single chunk of text in the project one by one, scanning through it, potentially writing changes and closing it. There are things in the software that do this because they have to, like redefining a style, and we can expect such a thing to be slow, but in this case it isn’t so clear, for the reasons given above, that links should even be “fixed”.

Overall though, I agree with the above: I can think of very few reasons to use Merge—and that’s especially true whenever the things being merged have been making use of the outline as a feature. If we just hammer out ten ideas in a row, flesh them out, and them merge them as a kind of process with no intention of those ten things ever being discrete, then okay. But if at some point I actually linked to those things, then why would ever want to destroy the structure that was evidently useful enough to refer to as pieces?

With compile and Scrivenings mode working the way they do, if a part of my text is conceptually better represented as pieces, there is no downside to leaving it that way. By extension there is no downside to leaving things in pieces even if I’m not actively using that aspect with links, metadata or other tools. Why not leave that option open?

1 Like

Ok, on the first point you make, I understand that there are cases where leaving the links as they are can be beneficial. But there are also cases where it is not, so why not, instead, leave an option for the user to decide how they want links to behave? For me it would mean a big change and it would help me a lot, I’m sure it could help many others as well.

And about the second thing, I think it depends on the case. I use Merge because I divide my novels into scenes. Sometimes I realise that two scenes should really be one (for content and other reasons) and the quickest and easiest way to make them become one is to use Merge. The same goes for Divide, which I use when I think one scene should be two. And scenes, as you can imagine, there are a lot of them, so I have to do this process frequently.
And, because I also take Snapshots to keep track of versions of my documents, it is not convenient for me to just copy and paste text from one scene to another. That’s why I use Merge and Divide, if you think of a better method to do this, please let me know :pray:

I hope that clarifies my point a bit better, thanks for your reply :heart:

1 Like

Yes, that makes sense, and Merge definitely is the best tool for the job as you’ve found, since it combines all of the snapshots and other inspector things that can be combined.

I just had another idea, what if there was a way to tell at first glance when a link has stopped working? Like, it would appear in a different colour or something, instead of having to mouse over all of them (because I have so many of them, some of them escape me).

That is of course a good idea, and that’s the type of thing that can be done with high performance. It is computationally simple to check whether the item a link pointed to still exists, as opposed to going through thousands of RTF files looking for links and deleting them every time you do something that would remove binder items. As I recall the Mac text engine can’t even do that though. A link is just a link, regardless of what kind of link it is, or whether it works. Because this is something I brought up a long time ago, that there should be a very visual difference between an internal link and one that goes to the web.

Windows may be a different story, I’ve put it on the list to see if is something we can do, and if so, maybe have some additional colour entries in the Appearance: Textual Marks: Colors options tab.

1 Like