Link Specific Text from One Document to Another?

I’d love a feature extension to internal document links where it would be possible to link a specific paragraph or section, similar to wiki software.

For example, if I have a document in my notes called Bob’s Personality that consists of a bunch of paragraphs, and I want to reference a specific paragraph in another document, like maybe a chapter outline or general timeline, right now that isn’t possible. I have to link the entire Bob’s Personality document and then scroll around until I find the specific bit of information that is relevant.

This is currently the biggest source of frustration for me in Scrivener for the purposes of note taking. If I could reference specific bits of text within a document, everything would be golden.


Here is a convenient trick that works if you don’t need to otherwise use Insert / Current Date and Time :
(Note that this might not be for you if you plan on compiling your final with comments included. Whether it is as comments or footnotes.)

Go to options, and modify the custom date and time like this:

→ You can simply copy/paste the following in the field :
→ [ddMMyyHHmm] ←
(That’s [daymonthyearhourminute] with brackets. )

This will generate a tag with a unique “serial number” anytime you’ll insert date and time. Brackets included.
. . . . . . . . . . . . .

Do not add extra spaces to make it look better. The brackets should be enough for things to be clear. Consider it as not being there at all, and input only the space you would have normally or not, should this tag not be there.

Double-clicking the tag selects the “serial number” inside the brackets :

Copy it → Ctrl-C
. . . . . . . . . . . . .

In the document where you want to link to a specific paragraph or passage or whatever, select the first word of that passage :

Add a comment :

Paste the tag number you previously copied to the clipboard :

Note that there is nothing preventing you from doing the operation backwards. Destination first as a comment, then the “link”. – That’s actually how you would have to do it in the case you’d want to link to a specific passage as the destination in multiple other places.
. . . . . . . . . . .

A few days later…

As your are working on your document, you want to go back to that spot you marked in another document.

Double-click the tag and copy it like before. (Ctrl+C)

Edit / Find / Find by Formatting...


Paste the tag number you just copied to the clipboard in the “Containing Text” field.

Click “Next”

Voilà :

. . . . . . . . . . .


  • The links go in the body text, the destinations in the comments.
    . . . .

  • The brackets are so that you can remove the tags at compile using the compile format’s replacements. A RegEx could easily do that. (You can also use a character attribute style, and have the compile format delete text of that style. This at the same time would allow to make the tags/“links” more visible and or of a tiny font should you wish.)
    You can use another symbol if you already use brackets elsewhere. The convenience of brackets being mostly that they don’t get selected as well when double-clicking. In the context that it is best not to add a space that would leave that extra space once the tag is automatically removed at compile, that avoids selecting the word next to it as well. (Brackets are usually author’s inline notes intended not to be part of the final published material anyways. Or at least that’s how it used to be.)
    You can use whatever symbol works for you if using brackets is conflictual, and rather select the “serial number” by hand, depending on the symbol’s behavior.
    . . . .

  • If you had planned compiling with the comments included, you can manually select the tag and paste the brackets along the “serial number” in the comment when creating the fake link. The compile format’s replacement won’t remove the comment, but at least the comment will be empty.
    If you convert your comments to footnotes or endnotes, same result. An empty footnote, but the superscript marker is left present in the body text.
    There might be a fix for that, I haven’t experimented with this yet. (Don’t hold your breath.) Any ideas welcomed.
    Worse case scenario, you’ll have to clean up those tags or “fake links” before your final compile.
    Since removing them from the body text is not a problem (the compile format already handling that automatically using RegEx or a character attribute style), you should only have the comments to delete.
    Searching for the brackets or the symbol you would have chosen to use via Edit / Find / Find by Formatting... (just like before) would make it relatively fast and easy. (Search for only the symbol, you’ll find all the concerned comments one after the other.)
    . . . .

  • Setting up a link takes no more than 7 seconds.
    Following a link takes even less. (Yes, I timed myself. :wink: )
    . . . . . .

  • Once you have followed a “link” to its destination, if you split the editor and click the back arrow for one of the two, you’ll have both documents side by side.


I tried to come up with a RegEx formula to automatically remove those tags from the body text.
I succeeded, adding a special character to the tag. Except for the fact that my current formula removes more than those tags.
I can’t get it to target those specific “fake links” and nothing else.
I am gonna need help with that, if anyone is so kind.

Say I add a special character and use { } instead of brackets.
So the tag would be something like {⁑0402231346}

The RegEx formula I had in mind would have been [{⁑\d}] replaced with nothing. But it doesn’t work.
It has to be conditional of the presence of ⁑.

Very creative, helpful and thanks for sharing. Intuitively, makes a ton of sense as well! Just one hitch, can’t find the setting for ‘insert date & time’ on the Mac Version of Scrivener. Anyone can help me with that?

It’s on the “Insert” menu, down toward the bottom.

35 posts were split to a new topic: On discussing design intent and outlining

I’ve improved the method a bit…

I redesigned it using a character attributes style. So that handles removing the location tags from compile if desired. It also takes care of the comments/footnotes issue in the simplest way, as well as operating outside of the inline annotations, allowing the location tags to be treated 100% apart from any other built in switches. Thus allowing to compile with inline annotations, comments, footnotes, while removing the tags that might serve no purpose in a compiled document. (Although in some situations they may. So it’s up to the user to decide whether to include them or not, leaving everything else untouched.)
Finally, using a character attributes style allows for all of this to happen without any RegEx involved. Which I believe is a big improvement.

I’ve included a project at the bottom of this post.
It contains 200 preadjusted tags that can be used to precisely jump from one location to another, anywhere should that be within a project.

Here is how to “install” those tags.
(Backup your project first.)

Once you have that project downloaded and unzipped, import the styles from it.
It has only one style,
so that is not gonna mess the styles list of your current project by bloating it.

Import styles


Once this is done, open that project side by side with your current one.
Drag the “Location TAGS” file from its binder to your project’s.
(I personally would place that file at the top of the binder. Above the Manuscript/Draft folder and the front matter. - By all means, don’t put it in one of those two folders…)

Once the file is in your binder, add it to project bookmarks.

That list of pre-styled tags is now accessible from within any document.

To use it:

Whenever you want to insert a tag that can be used to jump to a specific spot within another file, snatch one from that “Location TAGS” document.
It is easily accessible in the project bookmarks if you followed my instructions.
Triple click it, then cut it. (You want to cut it. Ctrl-X (not Ctrl-C). To make sure you’ll never use it again after this. → Picture that “Location TAGS” document as a sheet of single use stickers. You peel the sticker and then stick it where you want it.)
You can also drag and drop the tag from the bookmarks panel to where you want it in the main editor, then hit Ctrl-X while the focus is still on the bookmarks panel’s bottom section. As long as you don’t leave the tag in the list, for you to later mistakenly use it again for a different “link”.

Cut → Paste


That would be the “link to”.

Go to where you want that link to take you, and paste it again. Add a “D” (or whatever) to it, as in “Destination”.

And now, when you want to go from a tag to another, double click the tag from within the editor and copy it to the clipboard. (The brackets prevent the double-click selection to go beyond the tag itself.)
Using Edit / Find / Find by formatting :

This will cycle you through all of the instances of that one tag :

This will take you straight to the destination tag (the one you’ve added “D” to) :

To have all of those tags removed at compile, add the style to your compile format and check “Delete text of this style”.

That’s it.
Here is the project for you to download : (16.7 KB)

P.S. I have stopped using the TimeStamp thing since it seems that Mac users can’t customize it, and also, in my case (Windows user), doing things like I just depicted takes the step of assigning the style to the tag out of the equation, as I preformatted them.
I will have that “Location TAGS” character attributes style and the tags document + project bookmark as part of my new project template, giving me a fresh batch of tags with each new project, everything ready to be used with no further steps.

You can search for the tag in any of the other search fields as well.


Setting up one of these emulated links can be done backwards. Destination first. It doesn’t matter.
See my previous post for the full picture.

I am proposing this uniquely as an alternative to bookmarks for when you want to point within a paragraph, or for when splitting the document in smaller bits is for some reason inconvenient.

I’ve included 200 preadjusted tags. It should be more than enough. If you need more, compile a bunch of [≡<$n>≡], paste them back (starting at 201) in the Location TAGS document, and apply the “000 Location TAGS” style to them.


Something I think that is fallen by the wayside in this discussion is that it has revolved entirely around the notion that without this thing Scrivener is deficient, and whether or not that is the case, as opposed to what Scrivener offers instead.

To expand on something I’ve said in the original post, and again in a follow-up above, is that is I feel there are strong advantages to the methods described here that anchor & link systems have strong weaknesses with. I don’t think it is quite so clear cut as to say that one is definitely better than the other. I would even go so far as to say that the mechanisms we can use in Scrivener are probably better for writers than the anchor & link system, which is probably better for readers (the web page example again).

The kind of difference I’m speaking of here is similar I think to the differences in footnotes in a book, and footnotes in software. The way Scrivener handles footnotes is to my mind a superior model for writers in just about every way (other than perhaps visualising what the reader will interface with). Presenting footnotes in a manner that is best for readers in software has always struck me as awkward, particularly in page layout programs where the tendency is to make the physical page larger than the screen to overcome disparity in print quality. To write a footnote you’re taken off to another part of the screen, losing your context, and likewise have to jump around to read it later on. A footnote in a sidebar on the other hand is right there, readily available, and having an overview of all the footnotes relevant to the region of text you’re working on, stacked regardless of their actual distance in the text, is extremely valuable. This contextual pairing is even stronger with inline footnotes, which some prefer to use for that very reason. Your notation and what you are notating are immediately adjacent.

Where it comes to mechanisms that promote rapid navigation between textual markers we encounter clustering capabilities, bi-directionality, direction-less (or anticipation-based marking) and egalitarian marker importance that together create for a content-creation focussed environment. I can at a simple flick of my wrist assemble a list of all instances of a marker throughout hundreds of pages of text, jump to any one of them and remove it without fear of harming the rest of the cluster. There is no root anchor I must be careful around, that all satellite links depend upon for functioning, they are all root anchors until the last one is deleted. This elevates the concept of binding text fragments together into workflows rather than purely as end point to root point navigation mechanisms.

There are other operational advantages as well. I feel an invisible anchor mark in the text is less useful than a descriptive one. I don’t like how a hyperlink cannot be readily annotated for its purpose in linking somewhere. Sometimes a tooltip can tell us where we are going, but rarely why, and not without heaps of UI in the way in order to define that why. And the heaps of UI is certainly something to consider as well. The amount of clicking through panels and buttons in order to make an anchor & link in a typical word processor is far from efficient, whereas the mechanisms we have in Scrivener are just like typing. There is very little operational difference in binding two pieces of disparate text together as there is in typing.

To me, the way word processors handle this matter doesn’t feel like a writing tool—and I really don’t think it is. It’s a reader tool, like the footnote, that writers have historically used for their own purposes which, as I noted before, must be dismantled by hand before publication—because it is a reader tool.

The other argument is that one requires an “intricate” or complex system, which implies the other does not. To me that seems less an intrinsic necessity in any system or approach that targets a specific spot, and more a product of how frequently or extensively one uses it. You can have an intricate system using hyperlinks with point-to-point anchor points, and you can have an intricate system using markers. Both could also be used fairly simply, as well.

Perhaps a comparison of the two methods would better show how I do feel the marker approach is generally the most efficient approach to solving that specific problem, in a way that requires less technological overhead and manual labour, and meanwhile offers levels of flexibility that no single-direction linkage system provides—and thus with these considerable and unique advantages, hardly deserving of the phrase “workaround”.

Disclaimer: I am not by any means a word processing expert. I could be missing some really crucial details in here that would make some of the cons a bit less so.

Adding an Anchor Point

In Scrivener:

  1. Insert ▸ Inline Annotation
  2. Insert ▸ Current Date & Time (again I’ll just stick with that for simplicity, it is not a dependency).

Result: an obvious marker, easy to locate while scrolling around if that’s beneficial, and a “mindless” approach to generating anchor identity. A characteristic of this approach is that the opportunity for explanation of the link’s purpose is readily available. While we may not often need it, jotting down why we created an anchor in the first place is second-nature, and can be done immediately after step two by simply continuing to type. We can stop commenting by using the same exact shortcut we used to start adding the marker—and keep writing.

In LibreOffice:

  1. Use the Insert/Bookmark... menu command.
  2. Come up with and type out a unique marker ID.
  3. Click the Insert button.

Not a lot more in terms of raw manual labour, but when you look at the sort of mechanical and mental properties involved, there is more going on than seems at first blush. You have to come up with unique identifiers yourself somehow. Maybe you can use date as well, but that will make things difficult for you later, and not everyone has a handy universal way to insert dates everywhere. On a mechanical level there is a lot more mousing around by having to click on buttons in a GUI.

Result: an invisible marking in the document you’ll never stumble across without using sidebar navigation. Everything that must be known about this link needs to be communicated through the marker ID itself. There is little opportunity for annotation without invoking additional commands and inserting more formatting that must be removed later.

Scrivener variation: now, you might be thinking that the sidebar is actually a benefit of this approach that Scrivener does not have—but that is not in fact the case, and can be achieved with a simple adjustment to step (1): use an inspector comment instead—now you have it in a list. It’s not my preference, I prefer the seamless notate-while-writing that inlines give you, but if a sidebar for jumping to markers is vital to you, that’s an easy option.

Conclusion: since using lists of anchors with “mindless” anchor names is a universal problem, you’ll probably want to adopt the higher mental cost on the creation of each bookmark, giving them descriptive names—but if a navigable list is important to you anyway, then it is worth the cost. The datestamp approach has clear advantages for, as put above, quick and often times temporary links between two portions of text, whereas the uniquely named marker approach is better for intricate systems of cross-referenced markers. These are choices rather than requirements of any particular approach, in other words.

Linking to the Anchor

In Scrivener:

  1. Edit/Select/Select Annotation
  2. ⌘C / Ctrl+C (copy)
  3. Click into the place where you want to refer from and press ⌘V / Ctrl+V to paste. Here I’m assuming a split view workflow where both texts are scrolled into view.

Result: we now have a symmetrical linkage between these two points in the text. Both instances of the annotated date-stamp (or descriptive anchor, as you wish) have the same characteristics and method toward discovering the matching anchor.

In LibreOffice:

  1. Select the text in the editor to create a hyperlink from.
  2. Use the Insert/Cross-Reference... menu command to bring up the Fields dialogue.
  3. Select the “Bookmarks” type, in the upper-left area.
  4. Locate and select the anchor point you’ve created (here is where using dates alone would grow unworkable).
  5. In the lower left corner, select the manner in which the reference should be printed in the editor. For our purposes, this is somewhat arbitrary, but it is still something one must do, each and every time.
  6. Click the Insert button.
  7. Click the Close button.

Result: similarly to an inline annotation, we get a form of “meta text” inserted into the text flow. The actual identity of what we’re linking to is likely obscured. The only way to know before clicking the link is to reach for the mouse and position the pointer carefully over the highlighted area, and then wait for a second or two, until a tooltip appears. Not exact a good tool for skimming quickly and locating connectivity by eye.

LibreOffice variation: you may be thinking that I’m off on the wrong track, and that you meant a simple hyperlink rather than a cross-reference. I’m aware of that approach as well, but the workflow is not substantially less labour-intensive:

  1. Select the text in the editor to create a hyperlink from.
  2. ⌘K (insert hyperlink)
  3. Click on the “Document” button along the left list.
  4. Within the “Target in Document” section, click the target button to the right of the text field.
  5. Locate and select the anchor point you’ve created.
  6. Click the Apply button in the secondary pop-up.
  7. Click the OK button in the primary dialogue.

A bit less complex and laden with superfluous options, though I still would not consider that to be very user-friendly at scale (scrolling through a large list of bookmarks in that little pop-up for instance, sounds like the sort of thing that would drive one to other methods).

Conclusion: even with the slightly more straight-forward concept as the product, the actual result that we get still requires over half a dozen different actions from the user. The relationship we’ve established in the document between these points is very one-directional. We can travel to an anchor point from the link, but at the invisible marker where the anchor exists, there is no indication of what links to this spot, and no way to get back to those spot(s). So it is a decidedly asymmetrical linkage, unlike Scrivener’s—and as far as I know, the same goes for cross-references.

Linking to No Anchor

What’s this about? Well you don’t always know that you need to link to a place while you’re looking right at that place. In fact, for how I work anyway, I tend to realise I need to link to a spot elsewhere in the project, rather than coming across a spot and realising there is a spot elsewhere that should link here where I’m already working. The above examples all presumed we had the target in view, but what happens when we don’t?

In Scrivener:

  1. Insert ▸ Inline Annotation
  2. Insert ▸ Current Date & Time
  3. Edit/Select/Select Annotation
  4. ⌘C / Ctrl+C (copy)
  5. Navigate (using whatever method you prefer) to place where you want to refer to and press ⌘V / Ctrl+V to paste.
  6. ⌘[ / Ctrl+[ to return to where you were previously typing.

Of course, if you go back and compare the two checklists, that’s exactly the same list of steps! This is another facet of what is meant by having a symmetrical linkage between texts. It doesn’t only refer to the utility of the product, but a reduction in the complexity of the creation of that product. Where there is no cognitive difference between anchor and link, there is no mental burden in organising the information flow within a document. We do not have to select between two directional tools, we always do the same thing.

This is what I mean by having a “mindless” editing process. With our mind not encumbered by the particulars of establishing a directional linking system—having to come up with unique and descriptive anchor names, having to think in terms of link vs anchor, etc.—we can focus more purely upon the work itself, rather than the technology supporting it.

Content creation, not building a system for readers.

In LibreOffice:

Now here is where things get problematic. We’re at a point in the document where we’ve realised we want to link from this spot to another that is off-screen. If we simply go straight to that spot and proceed with the anchor point checklist, we’ve lost our place! So how do we solve that problem? I suppose one way would be to use the very technology that we need to create a link—it is a bookmark after all. So:

  1. Use the Insert/Bookmark... menu command.
  2. Come up with an type out a unique marker ID, maybe “RETURN POINT”.
  3. Click the Insert button.
  4. Great, now we’re off and scrolling around to find the target spot. Once we get there:
  5. Use the Insert/Bookmark... menu command.
  6. Come up with an type out a unique marker ID.
  7. Click the Insert button.
  8. Use F5 to load the Navigator.
  9. Locate the “RETURN POINT” bookmark and double-click on it to activate the bookmark.
  10. Press Delete to remove it.
  11. Close the Navigator window. And now we start in with the process of creating a hyperlink or cross-reference to the bookmark we just jaunted to and from. I’ll just pick one arbitrarily as they both seem to be about the same in terms of checklist load:
  12. Select the text in the editor to create a hyperlink from.
  13. ⌘K (insert hyperlink)
  14. Click on the “Document” button along the left list.
  15. Within the “Target in Document” section, click the target button to the right of the text field.
  16. Locate and select the anchor point you’ve created.
  17. Click the Apply button in the secondary pop-up.
  18. Click the OK button in the primary dialogue.

You might argue that I’m getting pedantic by spelling out each and every step one must take to create a link, from anywhere in the text, but I do think it is important, when examining two different approaches for their relative efficiency and utility, to go over all common contingencies in their usage. The first checklists looked at the two processes from the link’s most efficient context: where we have the intended anchor point directly in view. But like I say, we can’t assume that will always be the case, or even often the case. For myself, the above eighteen (!!) point checklist is often what would be necessary.

LibreOffice variant: while we’re looking at this facet of usage, I think it’s a good place to note that this checklist is roughly how one would achieve a form of symmetry in the traditional directional hyperlink model. We would only need to tweak this checklist in two places: first coming up with a stable and better unique ID for the starting point, and secondly, instead of deleting the anchor point once we return, inserting another seven-point checklist after step (4) to link to the first anchor we created, before returning and then linking to the second anchor.

So while the utility of having symmetrical linkages may seem appealing to emulate in a hyperlink model, once one sees their power and low mental overhead in action in Scrivener—I’m really not sure if it is worth the twenty-point checklist in order to achieve them, and the mental overhead advantages only exist within the product rather than in the creation of it.

Link Activation

Finally we get to the point where there can be said to be a clear advantage to the hyperlink approach.

In Scrivener:

  1. Edit/Select/Select Annotation
  2. ⌘C (copy)
  3. ⌃⌥G (focus or bring up the Quick Search tool)
  4. ⌘V and Return (paste and activate jump action)

In LibreOffice:

  1. Hold down the necessary modifier key and click on the link.

While activating the link gives a clear advantage to the hyperlink approach, we are still faced with the problem of returning. If we spent the necessary twenty steps to create a round-trip between the two points, then we can use that, but if not we are either faced with creating a temporary bookmark before clicking the link, or manually scrolling back to wherever we came from. So in a sense we can see that although the activation event is, in and of itself, more efficient, the burden of the full action is more so deferred, and arguably not too much more efficient as a net process.

Link Cleanup

It is unlikely that any of these kinds of links are the sort you want ending up in the output your readers will see. In traditional models the tools for linking or cross-referencing are really designed for creating reader tools in the end, and so by co-opting them for internal editorial purposes, we must go through and clean them all out once they have outlived their utility. I won’t bother to go through all of the various steps necessary to do so, or what one would have to do if they were also using these tools to create actual reader tools as well as tools for yourself. Suffice to say I’m fairly sure the process would involve manual labour at all points, removing in a one-by-one fashion the bookmarks and links pointing to them.

With Scrivener, since the links are all marked as “offline content” to begin with, we really don’t need to do anything at all. We could just compile and they will all be gone. If we were determined to clean them out, then we would see a similar level of manual labour. But the key point is that we don’t have to. We can, if we want, but there is no strong need to ever remove them. It could even be argued that leaving these kinds of markers around for future edits is very beneficial, as it establishes a network of relationships that could be of use to us when editing. A revision to text around a marker would incite us to look up that marker, and make sure all related text throughout the work is written in such a way to not conflict with the edit. We’ve already done the hard work in the past of identifying potential points of conflict!

That would be a useful tool in a standard linking model as well—but again you can’t have that, because then your reader is seeing all of those markings as well.

Direction-less Linking

I referred to this before, but to touch on it briefly: this is another content-creation biased capability that you don’t see much of in the traditional model, and that is anticipating that you may at some point need to link to or from this spot, without yet knowing whether you will.

With a marker based system you simply drop the marker down and jot down why. You can throw this into a Project Note in the inspector sidebar, and gradually build a list of these “loose threads” you are concerned about, as you write.

If and when you come across a spot that relates to that concern, you have the marker readily available in the sidebar. You might choose to remove it at that point, since now it is an established “cluster” (of two), or you might leave it around and choose to review your text and make sure this concern is well mapped.

In all cases we aren’t working about directionality. Our declaration of concern is made identically in all places, and can build from none to many without much effort.

And search results “of none” for this marker can be a useful editing tool in and of itself too. Knowing that you had a concern at some point, and seeing that you never followed up on it can be a reason to do some revision. Coming across an anchor point on the other hand doesn’t tell us much. That it was never linked to isn’t something the software can easily tell us.

I use that form of information quite frequently as a form of to-do listing. The to-do itself is a document somewhere with the marker created in anticipation, and I then go and place these markers into the text so that when the trigger happens—when that to-do becomes relevant, I know exactly where to go in the text. As I do so, I delete the markers from the “end points” until I end up with zero search results: that’s how I know I’m done.

There is probably more, and surely there are advantages to hyperlinks that I’m not talking about here as much. I wouldn’t want to leave off with the notion that I’m blind to what links can do, and that in some ways links can do some of the above, more or less. I just wanted to, as I put at the top, shift the conversation purely from a “Scrivener is broken and needs workarounds” stance to something more along the lines of: hey, let’s discuss what it’s doing well that focusses on the sort of things writers need to do in their text, that traditional linking struggles to provide as cleanly or efficiently.


2 posts were merged into an existing topic: On discussing design intent and outlining

I appreciate the effort to which the staff and community have gone to try and make this work through comparatively tedious workarounds when compared to what a direct link to a piece of content would just do. At the same time, I think the huge number of views this and other threads on this topic have received, demonstrates a common need among writers that literatureandlatte’s development team is either not seeing, or choosing not to see because a solution may be complex to code.

Yes, I can create a complicated system of tags that requires me to tag both ends and then search for the common tag, but this is fundamentally a huge time waster compared to how it could work. I shouldn’t have to use a 3-5 step process with multiple sets of keyboard shortcuts for something that could be completed in 1-2 steps max if implemented the most efficient way. In a single research paper, I might have 200 references. Having to spend 30 seconds following the suggested methods above on each of these adds up rapidly to where I’m spending hours per paper doing something that could have taken 2 seconds. Multiply this by the number of papers I write per year, and the number of users that could benefit from this, and that is thousands of hours lost because of a single inefficiency.

The very fact that it takes walls of text to describe these workarounds speaks against them. I shouldn’t have to spend 30 minutes trying to figure out how this even works. If it’s really going to be the only way forward for the next decade, an instructional video may be simpler, but what I get from this is that the only way forward until LiteratureandLatte makes it a priority, is to just direct link straight to devonthink files using their link-to-phrase system, which works beautifully, effectively, and efficiently. Is it ideal to have to be running two apps just to make this work? No. Will it save me hundreds of hours in the long run? Absolutely. And I think it’s sad that this isn’t obvious to everyone else here.

Apologies if this comes across a little sharp though. I do appreciate the effort and interest in helping your user base. This just seems like a very simple, yet somehow intentional oversight based on the archaic, subjective preference of a few.

It’s easy for people who don’t have to actually write the code to dismiss “complex to code” as a trivial objection.

It’s also extremely normal for people to think that their own priorities are common across the entire user base.

Personally, if I routinely handled hundreds of references, I would use a bibliographic reference tool designed for that purpose. Replacing such tools is not something that Scrivener has ever been intended to do. I also find that DevonThink + Scrivener is an extremely powerful combination, allowing me to exploit the strengths of both while at the same turning “off” functionality when I don’t actually need it.


I don’t intend to trivialize it at all. I’m not completely ignorant of coding. I’ve also done my fair share of comparisons to get a good idea of what companies offer and what people use. I’m in no way suggesting Scrivener should attempt to become a bibliographic reference tool. That is not the function of inter-note tagging, so I think you may have misunderstood the intention here in an effort to trivialize this concern. The purpose is to help connect ideas and save time in the review, navigation, and sorting process of research-based writing.

There is enough discussion with people here using inefficient workarounds along with the number of views to suggest that there is a reasonable degree of demand. Scrivener literally has a manual with 900+ pages of awesome features many people aren’t even aware of. I’m just highlighting that this is a potential oversight. Happy to post something more constructive in the feature request section.

1 Like

“What is the best way to connect ideas?” is a much more interesting question than “why can’t Scrivener link to a specific location?” And I think if you look around the software universe you’ll find that there are almost as many ways to answer it as there are researchers.

You’ll also find that the “best” answer varies a great deal depending on the specific project and field. Even “direct link to a piece of content” means something different to someone doing close analysis of a piece of literature than it does to someone presenting experimental results.

1 Like

I’m more interested in what is most efficient while functional than simply “best.”
As you note well, best is subjective.

But there are trends, and as my note app comparison shows, many note and writing solutions already offer section-specific linking. People do know what that means and commonly use it. I can appreciate that you do not have a need for this just as much as I know others do.

If you define your wish as “section-specific linking,” the canonical answer in Scrivener is “Sure, we do that. A Binder document is a ‘section.’”

But then it turns out that you (and others) don’t like that answer because you think it’s too confusing to have hundreds of “sections” for your reference notes. Which is fine. You’re entitled to your preferred methods. From our point of view, though, we already provide exactly what you say you want. In fact Scrivener is designed from the ground up to do exactly this. We (and many many users) have tested our approach and found it to be extremely robust and flexible.

I’ll stop beating the dead horse, here, but do you see why we find it extremely frustrating when people demand – at great length – something that from our point of view we have been doing since day one?


Breaking one’s text into small chunks is unworkable without a robust Scrivenings mode to stitch them back together into a virtual document that seamlessly replicates working in a physical document.

Apparently this works well on Mac Scriv.

For Windows Scriv, not so much. Limitations of the QT framework have in turn limited the implementation of Scrivenings mode in Windows, such that basic navigation features don’t work across the physical document boundaries. This impacts page up/down, home/end keys, text selection, and possibly other features of the editor. As a result, while I do use Scrivenings mode on occasion, I tend to avoid it, and therefore tend to avoid breaking my documents up into small chunks.

Katherine, are you aware of these issues in Windows Scrivenings? Based on your post above which takes the position that the infrastructure has already been implemented and working perfectly in Scrivener, I’m thinking you’re not.


I do most of my own work on the Mac, so while I’m aware of the limitations of the Windows version I admit that I’m not directly affected by them.

The solution, though, is to fix Scrivenings mode under Windows, not to propose a completely new paradigm.

Sure, I agree heartily. I would love for Windows Scrivenings to function as it’s supposed to, and support Scrivener’s core concept of building docs in smaller chunks, with all the benefits thereof.

But, as per @AmberV, it is not a bug to be fixed, but rather a technical limitation, presumably in QT. Hence, unfixable.

It’s not that it’s too confusing. It’s that there is more than one kind of personality and person in the world. I can illustrate this by borrowing from MBTI concepts, whether or not the whole classification system is regarded well.

There are those who love the aesthetic and experience of things like journals, 3x5 cards, and writing things down by hand. They organize ideas with cards and scraps scattered throughout their room, or post on sticky notes all over an empty wall. They do things visually and creatively. Time is subordinate to the moment. This is largely who Scrivener caters to, and that’s awesome for this group of people. These are the intuitives who think abstractly and need to pull ideas together in this way because that is how they extract what they need to write concrete ideas down.

But then there are those who think differently. The sensors, the ones for whom extracting and describing information concretely comes naturally and without as much difficulty. Yes, we appreciate how binders combine documents, but we just want to get work done. So instead of separating everything out into hundreds of virtual 3x5’s (because we don’t need to take as much time organizing them), a thematic approach is much faster. We appreciate some aesthetics, sure, but prioritize efficiency. We are not as interested in tediously separating out, naming, and organizing hundreds of little notes in a binder document or geo-spacially grouping them visually on a virtual corkboard. For us, a simple in-line link directly to something will do, without all the aesthetics and extra steps of separating everything out, without naming, tagging, and organizing them separately for hours. The beauty of this experience for the intuitives is simply a needless chore for the sensors. And that’s ok. Each group has its space and workflow, but one is naturally catered to more closely by Scrivener, and it’s the former of these two.

I think this represents a neat opportunity for expansion. Others may see it differently, or not at all, as seems to be the case. Perhaps someday that may shift.


I understand that the opening of links is controlled by File > Options > Behaviours > Document Link…
But I don’t want to be tied down by a global choice for every situation.
Since there’s a Context Menu choice on how Bookmarks are opened, why not add the same to the Context Menu that displays when right-clicking on a link?
The Context Menu already has an Open Link as default, so add choices to that option.
It saves a few unnecessary navigation steps of getting to the document I want to access.
The capability is there, just not the quick access context.
The Context Menu (sub-menu) choices would be:
Current Editor — what I’m after sometimes.
Copyholder —I prefer not to work in side by side mode.
Other Editor — same as previous point, including not using above and below mode.
Quick Reference — my preference for most links and my set default.