Link Specific Text from One Document to Another?

AmberV · July 6, 2020, 2:54pm

This is a very broad topic in Scrivener, as you might imagine, and in my opinion it is one of the areas that it really excels in over other tools on the market. This is an area that is best described as a gestalt of practices and multiple smaller features. That means much of how you do things will can be interchangeably swapped out to taste. The core approach itself is quite simple—basic almost—but it creates a foundation upon which we can build predictable complexity, if necessary. Most of what you read below are techniques I use in the same project, it depends on what unique advantage I want from the approach, and since they are all closely related in the basic features they work from, different techniques can mingle in similar workflows.

This is also something that gets asked about quite a lot, and I’ve always had it on my list to pull together smaller notes and ideas from past threads and discussions on the matter, into one place. This will be quite long, I hope you do not mind.

Keeping Things Small

When this comes up, the first thing I like to point out, which can often passively mitigate the need for anything like direct linking in the first place, is that the software in general works better the smaller and more individually topical each chunk of text is. The inclination, especially coming from word processors, is to pack long texts, like whole chapters, into each “file” in the binder. Scrivener on the other hand works just as well if one “file” is an abstract concept that is technically fifteen or twenty smaller binder items. Scrivenings mode makes it possible to work with them as one, and of course the compiler does that naturally by its design.

My rule of thumb: when I feel a section needs more metadata or easier ways to get around within it, my first reaction is to break it up into smaller subdocuments.

In short, if the chunks of text in your binder or short enough that scrolling is a rare thing you have to do in the first place, then odds are very high that any general link to the item itself is going to suffice for specificity.

Marking and Navigating to Any Text Precisely

Working with small chunks of text is all well and good as an ethos for using Scrivener, but there are times where it is not appropriate to split up a chunk of text (especially not for purely mechanical reasons like linking), and of course some people just don’t like working that way. While Scrivener is designed to get better the smaller chunks are (and hopefully the above illustrates to just what degree I mean that), it certainly is quite good even without doing so.

The technique that I use to directly link to any spot in the document is best described as a mix of two ingredients:

An approach that has worked for decades: simply put a marker in the text where you want to link to, and then reference than marker from any place you want to link from. This all by itself is so basic you can do it with nothing more than a plain-text editor in DOS—it’s a technique that can survive migration to and from nearly any software, and will remain robust for decades to come. It is also by nature a two-way link, since the marker is the same in both places. This is of course very similar to what we were doing before, more casually, with note titles and selected hyperlinked text.
That all by itself requires some technology to make it convenient, however (never mind some convention for stripping them out when it comes time to publish). With Scrivener, along with some stock macOS tools, we can make this process extremely efficient, and only a couple of small steps more involved than clicking on a link.

The attached project is a simple demonstration of how this technique can be used.

linking_to_specific_texts.zip

In Document A, you’ll find two examples. The first is a purely internal link for my own benefit. It is placed within an inline annotation so it won’t compile, and in this case the link is just the marker itself. The second example shows how a “public link”, one that your reader might see as a cross-reference, is followed by an annotated marker. (Whether links become public is a choice you make when compiling.)
Both can be used in fundamentally the same fashion. Place the cursor anywhere inside the inline annotation, and use the Edit/Select/Select Annotation menu command. Since I work with inline notes a lot, I’ve added a custom shortcut to that command. So I just hit Ctrl-Shift-A.
The next step is to press Cmd-E, which corresponds to the Edit/Find/Use Selection for Find command. This, by the way, is a common Mac shortcut you’ll find almost everywhere and it even works between native Mac programs. What it does is basically “type” this text into the Cmd-F find tool, but without bringing that window up. It’s purely in the background.
Now we click the link to load the document with the marker in it.
Hit Cmd-G (or Edit/Find/Find Next). This is like clicking the “Find Next” button in the window, but again we don’t need the window for any of this. We jump straight to the right spot in the longer document.

Again, this is just one approach. We may just as well use Quick Search for this, replacing the click + ⌘G step, and given Quick Search’s previously explored navigation + auto-scroll behaviour when selecting text matches, it is very efficient. You will note at that point you don’t even need a software link, but it’s probably handy to have one anyway (particularly for that handy back-link bookmark feature).

Creating Direct Links

In this example project the unique marker is being generated by simply inserting the current date and time. This is made convenient in Scrivener, which has a command for doing so. Try this:

From either Document A or B, put your cursor somewhere and press ⇧⌘A to start an inline annotation.
Use ⇧⌘⌥D or Insert/Current Date & Time. (You may note I type in spaces before and after that command as well, as I think that looks nicer and doesn’t confuse spell check.)
As above, use the command to select the inline annotation and press ⌘C to copy it. Now you’ve got the whole thing (marker + notation formatting) on the clipboard, for pasting in the precise location you want to link to.
The precise method you use to link to the document is up to preference, as there are many ways of doing so, but a good trick to be aware of here is that if you drag an item onto a selection of text, that text will be linked to the item. Again the Swiss Army knife Quick Search tool is superb for this task, as you can locate the target item swiftly, drag and drop it out of the result list onto the text to make a link.

Alternatives & Ideas

The date stamp is convenient, but it may not always be informative enough by itself. Often when I link to something, I prefer to jot down why I am doing so, so that in a year or two down the way I don’t find myself blindly following links in the off-chance there is some important reason for having done so in the past. Here are some ideas for making these markers richer:

Sometimes I like to know whether what I’m looking at is a “target”, and I’ll use a way of marking the marker to indicate that. For myself I have a system I’ve been using since 2004 or so, where outbound markers look like “<|re20186737|>”, and inbound markers look like, “>|20186737|<”. This is an extremely compact format that indicates directionality, link type with the prefix (“re” in this case, indicates the link is going to bring up a piece of communication that this text was composed as a response to), followed by a condensed year+day+time format.

This approach also gives me information to search for around the specific marker. Running a project search for “<|re” for example, has obvious potential.

For most people, that’s probably too dense and cluttered and complicates the selection process too much, but it might give you some ideas for how you could do this. I prefer plain-text solutions, but you might be more comfortable indicating outbound links with red annotations and inbound links as blue, to provide Scrivener-specific approach.

Or maybe you like the idea of text, but want something that looks nicer. Just to pull from one category in Unicode, arrows provide an veritable wealth of semantic information, making “⇇20186817”, “⥵20186817”, “︎20186817” and “︎20186817” all individually meaningful and capable of search tricks. Had I developed my system in 2020 instead of 2004, I’d have probably gone with Unicode symbols over ASCII!
Markers like this can do something that software hyperlinks cannot do, they can create a cluster result of relative points of interest in a large pool of data, where any one of those instances is an entry point into the rest of the cluster.

Returning to the sample project, the second example shows how a marker needn’t be linked itself—maybe this particular marker is placed into a dozen different binder items, and we are less interested in getting to any one of those, but would rather see all of the cluster. To use a marker in this fashion, one would copy it using the previously described technique, with ⌘C substituted for ⌘E, and then paste the marker into the Project Search tool. You’ll get a precise list of matching items in the left sidebar, and can flip through marker hits in the main editor with ⌘G (the software will do the ⌘E part for you whenever you use project search). Commonly referenced markers are excellent candidates for saved search Collections.
Combined with a systematic approach to marker creation, cluster results like these can be predictable. Date and time is handy, but sometimes a cluster is important enough to be recalled at any time without having to find an instance by hand to know what marker to search for. This is when I use generalised markers, like “RSCH//” to indicate bits of text requiring further research, and that may be all I put into the inline annotation—I might also explain myself after the slashes, it’s flexible.

And of course, having a convention like “//” all by itself gives us the opportunity to very easily jump from one edit note to the next in a broad way, via the Edit/Find/Find by Formatting tool, set to inline annotation search mode (and again, not colour can be used semantically by that tool, if you prefer that to plain-text approaches).
So to combine these different threads together, in some cases it might be very beneficial to have an annotation like this: “TODO// 2020-07-04 at 18:51”. Now you’ve got two things going on here. You can hop directly to this chunk of text from anywhere else since it has a unique marker, but you can also locate this generally, by running a project search (likely as a saved collection, for something like an embedded To Do list!) for “TODO//”.

Lastly, a few alternative tools that could be swapped around within the framework of this approach:

I’ve used inline annotations in all of my examples. I like to keep stuff like this in my face, so I can’t ignore it, and as easy to interface with as the source text itself. Some do find it obtrusive however, or may struggle with clutter if their note-taking/tagging is dense. The Comments tool can substitute for every application above, and in some ways offers a superior feature set, as it builds a navigable digest of your note markers in the sidebar. The downside is that you have to use GUI techniques to access them, rather than simple text editing techniques.
Styles are a newer tool to Scrivener that have interesting potential in this area of use. They follow the inline annotation principle, but styles used in this fashion can be set to delete their text when compiling—and because they are styles, you can codify meaning right into the marking itself. You can click on a linked date stamp and see “Research Note” printed in the Format Bar. Styles can also be searched for using the formatting finder, and the Styles panel also has a convenient up/down arrow control for jumping from one related marking to the next.

Explore the various marking systems described in the user manual, in Chapter 18. Most of these are capable, some quite simple in their usage, and all can be very precisely targeted with the various searching tools.

So while Scrivener does lack a webpage or word processor style mechanism for linking directly to a chunk of text with a single click, hopefully you’ll find something in here that works for you, that provides that same capability. In my opinion, even if I had the option to create a simple direct hyperlink, I probably wouldn’t use it much, because I really like being able to describe what an editing link like this is for. Simple hyperlinks have none of that, they are just blue text you click on.

Notes as Files

Next, we’ll explore some practical techniques that take advantage of the concepts described above.

So I’d love to be able to go into my revisions/notes document, and have a link to a specific section of text in chapter 1 that I can click on and will take me to that section of the document. It seems like I can do the reverse of that - highlight text in chapter 1 that will take my to my revision document, but it doesn’t go both ways.

Now as to specifically what it sounds like you are doing here, there may be a dedicated mechanism in Scrivener that was designed for just this sort of thing, which in turn has a byproduct of giving you a “hook” to finding a specific spot of text:

Select the text that you wish to remark upon.
Hit ⌘L, or use the Edit/Document Link/New Link... command, if you prefer the mouse.
Leave the name as generated, and select where you’d like to gather notes for this chapter.

And off you go. See what’s going on here? Every note will have its own individual document, and most often you would create a folder for each major section (such as a chapter) that serves as a listing of all the notes about it. Click on that folder and you’ll get the notes as a corkboard, outliner or Scrivenings session. These notes can be organised, tagged with keywords or other metadata, and even selectively compiled if that is what you want.

Tip: what happens when you create a new link is up to you. Settings for this are in the Behaviors: Document Links preference pane. The Copyholder option has become my favourite over time, because it leaves me free to continue writing and editing in the original context, if that is what I want, or I can very easily jump into the copyholder with ⌃⌥⌘D and type in my thoughts.

So how do you get from that, to what you want to be able to do? Since we are leaving each note’s name as the linked text itself, we’ve got everything we need to find that text again easily, from the note. Try this:

From the note, hit ⌃⌥⌘T to shift the cursor into the title field.
Press ⌘C to copy, ⌃⌥G to open Quick Search, and ⌘V to paste.
You’ll get two results—one being the note itself of course! What you’re interested in is the result in the “Text” section though. Select that, punch DownArrow + Return, and the item will open with you scrolled right to the text.

If you’re a fan of macros, you may note how this procedure is quite predictable. If I used this technique a lot, I’d probably set up a single hotkey, like F8 that does all of the above automatically.

Keeping Change Logs

If I’m overcomplicating and there’s an easier way to do this that would be great! But I’d love to be able to look at one document that has a list of things I want to change that is linked to the text I’d like to change.

Now this is something I do a lot of in some of my projects! Each revision might impact a broad swath of items in the Draft folder, and I like to have a central nexus where I can jot down why I’m making this change, make little todo lists of things I’ve thought of that might be impacted, and so on. In short I like to document what I’m doing for the sake of my future self.

I have a top level folder in the binder for “change logs”. Within that is a list of sub-folders, each collecting milestone revisions in the draft as a whole. Within that are the specific notes on edits that were made, as individual binder items.

You may well be thinking that the previous tip would be a great way of building this list of change notes, and you’d be right! With one small adjustment, my approach while working through the text is: when I spot something that needs fixing, I create an inline annotation, and type a phrase to identify this edit to myself, as a link. This link won’t be seen in the output, nor will its text, thanks to the inline annotation. The New Link tool remembers the last place you filed a note, and uses the linked text as the name of the note by default—so for me I never even look at that dialogue, I just punch the Return key.

That’s how I create a new entry in the current milestone folder, but to insert another related edit marker elsewhere, sometimes I will use Quick Search to look up the log file and drag it into an inline annotation to link it into the text. But more often than not, thanks to the Copyholder workflow I mentioned above, I’ve already got that log on my screen. I can be updating my notes about the editing process for it as I work through the manuscript, and I can drag the icon out of the copyholder header into the main text editor to create a quick and simple link.

Using Notes as a Nexus

An important ingredient to this workflow (and many others for that matter) worth bringing up is the Bookmarks pane. If you’ve been trying out this technique as I describe it, then navigate to the change notes item using whatever method you prefer, and open the Bookmarks inspector tab. Each time you linked to this file from anywhere in the Draft, Scrivener recorded that action as a bookmark. You have an automatically generated list of areas within your draft that relate to this specific edit. A year from now, if you need to change another thing that relates to this particular aspect of your work, you have a “to do list” all ready to go!

You can of course also add bookmarks by hand, which I sometimes do instead. It depends on the kind of edit I am doing, as sometimes I want a back-link from the manuscript to each change log file that has impacted it over time. Often, since my chunks of text are so small, I don’t need an inline annotation. So in that case I drag the Copyholder icon to the Bookmarks list rather than into the text—that’s all it takes, and doing so creates a back-link from the nexus as well, so they both refer to each other in that same list.

And again, that preference pane I referred you to is where you can tweak how bookmarks and links work. Myself, I prefer to use these tools for navigation, so “Current Editor” is what I set them to. But for chapter notes, any of the other options are best for a referencing approach vs navigation.

E.g. if you use “Other Editor”, and load all of your chapter notes into the other editor as Scrivenings, then clicking on links or activating bookmarks scrolls the editor to that note. You basically get exactly what you’re looking for with that combination of settings and features, and with very low overhead. You’re letting Scrivener do all of the hard work of building lists of notes, back-link lists and so forth.

Using Snapshots to Identify Edit Points

I could mark each edited piece of text in a section, but more often than not I’d rather just have one link or bookmark and let Scrivener handle the dirty work of tracking the edits down to words and sentences. Here’s how you can do that.

When you are done editing a section and are ready to move on to the next, create a titled snapshot, the via Documents/Snapshots/Take Snapshot with Title command, pasting in the edit log’s title.

In this hypothetical year from now, you can jump to this specific chunk of text in the Draft from the nexus note, open Snapshots, select the related editing marker along with the previous snapshot, and hit the Compare button. This will compare the changes made between the one you marked, and the state of the document the last time it was edited (if you use this technique religiously, you’ll have a tidy list of edit logs as snapshots for each item). You can also see all changes since then, by only selecting one snapshot of course.

And that’s why I don’t bother doing the manual labour myself! Just get me into the generally correct part of the binder, and let Scrivener handle the rest.

Comments

One small mention here, but for some small notes, the above is a bit overkill. I’m sure you’ve already explored them, but the Inline Annotation and Comment features, in the Insert menu, are often the best tool for the job, and are by their very nature bound to specific pieces of text.

But, for long form notes and more complex organisation techniques, nothing beats Scrivener’s pure outline based approach. You will run into limitations with simple notational text, like being unable to gather them by kind in search results, etc.