Updatable links to documents in other scrivener projects

Scrivener
1

Use case with current workaround:

  1. I finish book 1 in a series and realize I’m going to make a trilogy in this world and so a “bible” would help. And: there are already lots of internal links all through this project.
  2. I create scrivener project Bible.scriv to be that.
  3. I take a bunch of documents in scrivener project A and copy to project them into the Bible (thanks tons for that functionality BTW: I’m surprised how often I use it, and I love it!)
  4. Then I use “right click and copy document link” to collect all the old IDs (in project A) and the new IDs (in project Bible) in a google sheet, of all things.
  5. export that sheet as CSV
  6. run a little script that is “full of danger and risk, so best not detailed here” involving s/ID1/ID2/ on all the A.scriv/Files/Data/*/content.rtf files (and a comparable version for the new content in Bible.scriv since the new information there often has cross links also). That replacement also changes scrivlnk: to x-scrivener-item: and obviously adds the full paths (because relative paths don’t seem to work, at least on macos (intel)).
  7. Bingo! I celebrate. Because I love the way that x-scrivener-item works seamlessly and so wonderously, the fact that everything in this universe is plaintext so I can pull off a stunt like that, that I magically have a working Bible, and that I can still link in+out of that bible into my other projects that use it, etc. Yay!

Feature Requests:

  1. In step 3, a “move to project (and update links)” option in addition to the “copy” flavor (which doesn’t update links, for good and obvious reasons) would be sooo helpful.
  2. In step 6, it would be really handy for x-scrivener-item to be able to handle relative paths (this may be out of your control), so that if (actually: when) I need to move some of these projects (because e.g. they now belong in a folder for the series, etc.), I wouldn’t have to hack my script and re-run it to update all the paths.
  3. I would love a Project Setting where I could list external reference projects (e.g. Bible=>../Bible.scriv) such that when I opened a project and discover that Bible.scriv is now in a different place, the user could be asked where it is now, and the new path would be used for links to that reference. I recognize that it might be non-trivial to implement this one.

So: how’s that for 3 feature requests bundled into one?

2 Likes
2

Nice solution for fixing your links in bulk! As you say, probably not something everyone should try, but glad you got it figured out.

In step 6, it would be really handy for x-scrivener-item to be able to handle relative paths (this may be out of your control)

Some systems even eschew paths entirely and abstract all of that, so the first part would be a UUID or something—but then you need a tracking system that knows where all of the files actually are, and then things get a bit complicated and top-down rather than purely document-based as Scrivener currently is. That’s a surprisingly big design shift.

The problem with calculating relative links though, to mind is, relative from where? Open Terminal.app, type in open with a space after, and paste your x-scrivener-item link. These links can come from anywhere, and indeed their original intended purpose was for other software to be able to embed them for link-backs, or to make proofing documents better (there is a compile option to automatically generate them at the top of each binder item).

In step 3, a “move to project (and update links)” option in addition to the “copy” flavor (which doesn’t update links, for good and obvious reasons) would be sooo helpful.

That wouldn’t be impossible (as you’ve demonstrated), but I do think that would add a lot of lag to such a command. It would have to scour every single rich text file from top to bottom, opening and closing hundreds or thousands of files every time. I guess it wouldn’t be the end of the world to put a spinner up after using it, but I do wonder how often this is actually done. Is it worth spending time on. I don’t even ever recall anyone asking for a Move To Project command, let alone the rest.

I would love a Project Setting where I could list external reference projects (e.g. Bible=>../Bible.scriv) such that when I opened a project and discover that Bible.scriv is now in a different place…

And that’s the same problem all Bookmarks have (whether Project or Document Bookmarks), when it comes to file system links. Hmm, we do already have a Documents ▸ Change Alias Source... command, that appears when selecting an alias/shortcut in the binder (which points to an original on the file system). It might not be a bad idea to have that command change to Documents ▸ Change Bookmark Source... when a file:// type bookmark is selected. It’s a bit muddled in “Documents” though, so maybe such a thing would just be better in the context menu for right-clicking on bookmarks anyway. I’ll jot that one down for consideration.

Thanks for the notes and sharing your process!

2 Likes
3

Ah! Yes, I see that now, and like it. In that case: please don’t change them. There’s huge value in that. Cool.

I don’t have good signal on this, but it’s certainly the right question for you to ask.
And since I’ve got a (messy) workaround: the number of people is one less (haha!). But if “one less” makes a difference, then the number is already definitely too small.

More than good enough for me!

Really love the product and the people that make it up. Thanks!

1 Like