I’m working on large project a book.
I want to use Bookmarks to get to a particular place in the document.
However, when I go to View -> Text Bookmarks the menu is empty unless I am on the page where the bookmark is (which eliminates the usefulness of using bookmarks to go quickly somewhere in a large document).
If I select everything in the binder the bookmarks appear but it takes a very long time before they do.
It seems that before bookmarks are accessible Scrivener has to read the document and find the bookmarks within it?
This is less useful for a large document.
However I looked for the bookmark just after opening the project. After a while maybe Scrivener does it reading in the background and catches up?
Yes, bookmarks aren’t really that useful because of the way they work, and are being removed from a future version. Theres’s no way to jump immediately to a particular location in a particular document, I’m afraid (and no plans to add anything like this in upcoming versions, which isn’t to say that it will never be added).
All the best,
Keith
“aren’t really that useful” is an understatement, and wouldn’t it be nice if the manual explained this?
The user manual phrases things in standard Scrivener terminology, wherein the word “document” does not refer to the entire Scrivener project, nor any collective segment of that project (such as the Draft folder, although one can think of the Draft as being “a document” in a conceptual fashion, if it will be compiled front to end as one file, this isn’t a technical description of it). A text document, how the manual uses the phrase, is specifically one single item (of any kind) in the Binder. So when it refers to the usefulness of this feature in relation to “text in longer documents”, it means specifically that, long text items that are unwieldy to scroll through given their length, that have not been broken up into smaller chunks for whatever reason.
What you are attempting to do is something the software can do, by the way, it’s just not automatic about it, instead it is extremely flexible and powerful about it. 
You can use inline annotations to put down a searchable marker in the text to tag a spot—inserting the date and time is convenient and easy for that since both have a keyboard shortcut. What I just described is achieved with Shift-Cmd-A + Shift-Opt-Cmd-D. That part right there is fundamentally very similar to the existing Text Bookmark feature—we’re just using something a little more unique and expressive than an asterisk.
How you use that marker is up to you really, but keep in mind you can load a string of text into the Find tool with Cmd-E and that Cmd-G will find the next instance of that text, all without even bringing up the Find panel. What I do myself is store the marker with the link pointing to the document. Want a master list of bookmarks with stored markers? Project References are great for that, even just a list of hyperlinks in Project Notes. And of course the technique works from other areas of the Binder as well, such as links hidden within inline annotations, and this concept even can be taken completely outside of Scrivener! You can right-click on the document you wish to refer to, copy its document link, and then paste that into say, OmniFocus and supply the marker as well. Now when you come across that To-Do item in the future, you click the link, Scrivener opens the project if necessary, opens the document within the Binder, and you have your marker ready to search for.
As you may have noticed—I use this technique quite a bit, in and out of Scrivener. 
Like I say, it’s not as automatic, but it hardly takes any effort at all to make a link like this, and naturally the concept itself is so core to computing and broadly powerful that it barely even need Scrivener in order to function. It just so happens Scrivener has a cornucopia of ways to build a web of interconnections between documents, so it works quite naturally with the concept.
Duly noted, but it’s not even that difficult.
I can create a bookmark, select all documents in the binder at a future point in time, and now going to that bookmark is not so difficult after all.
⌘ G only searches in the current document, so that part of your method is very limited – unless we select all in the Binder as mentioned earlier.
A crucial component of what I was describing is a link to the document containing the marker. A bookmark list that exists “above” the realm of individual documents must by some token be a group of links (either using internal Scrivener Links, References, or external document URLs) that lead to those documents. When you access the link to the section of text you wish to look up, you are linking to that document, and then of course once you are there, Cmd-G functions. If the link is by name, or annotated in some fashion around the link, the marker you need to search for once you get to the document, then you have both ingredients necessary to get to any paragraph in your project.
I suggest linking because to me that feels more direct, but there is another way that would not require a hyperlink to the section with the bookmark. Since the marker is placed in an inline annotation, you can use the formatting finder tool in inline annotation mode to search for the marker string. This will trawl the entire project to find it, and so thus you don’t need to preload anything or even know where you are going to find the marker. To me though, in most contexts where I would be making note of a marker in the text, I would be doing so in a place that can hold a hyperlink, so it just makes more sense to link to the document and Cmd-G from there, rather than copy and paste the marker string into a special tool and have it search the project for the document. For a plain-text list though, that could be an option.
Yes, as you mentioned in your first post however, that requires loading potentially vast chunks of text at once, merely to get to one location out of that text.
If I’m getting to the document via other means – which I think you intend me to do with your method – I don’t need a bookmark. I break my book into scenes short enough that scrolling to the paragraph I want is not a huge task.
Similarly, the way I work doesn’t make building the links you speak of make a lot of sense to me. The Binder serves that purpose well enough unless I need the same document many times over an extended period of time. In that case, I can put an internal reference in Project References – but it’s worth doing only in that limited case.
I wanted a shorter-term solution that’s faster than scrolling through the Binder, then scrolling through the document, and i don’t think you’re proposing a method that fits the bill.
I’m not the OP, so you’re talking about someone else. But I get your point.
Well okay, I was mainly coming at this from what the OP (sorry for the confusion) was describing as their trouble with the feature—needing it to be global. I tend to use the described method more for linking from a point to a point, rather than the separate bookmark list idea. A typical example would be a paragraph that benefits from information found in other paragraphs elsewhere, a simple internal “see also”. So for cases like that, the Binder isn’t the most efficient tool (especially considering that my Binders tend to have hundreds of items and I very rarely keep them expanded beyond the second level of hierarchy). But, it struck me that the OP was looking for a similar thing in general, the only major difference being that they want a global list of specific locations in the text. Whether you use the method for “see also” from within text to text, or from a master annotated list of links in Project Notes (or whatever), the method works fine I think.
If one does not need that, if their sections are very short [size=80][1][/size], then a simple list of internal links, References or a Collection is perfectly fine. If you don’t need to recall where a specific paragraph is during an editing session, then a general topical drill-down with the Binder is fine. So yes, what I described above is a specific tool, but it seemed to be something the OP was looking for, a very specific tool that has a paragraph level of specificity to it.
I’m not really clear on exactly what you’re trying to make more efficient, though, that wouldn’t be addressed by one of the several mechanisms for making lists of documents (and thus making the Binder concept more concise for a specific purpose).
[size=80]
- This is very often the case for me as well, so I get what you’re saying about that—and this is one of the reasons Text Bookmarks are being retired in the future, as it kind of goes against the grain of the software in that indexing a long chunk text shouldn’t be necessary; that is what the Binder is for.
[/size]
My sense is that what I need might be somewhere in Chapter 18 of the Manual (“Annotations and Footnotes”), but that I will have to read the entire thing to figure out if what I need is there. Your post has led me in the right direction, and I am now learning how to create various things—footnotes, linked footnotes, inline notes, annotations, comments—but I am still struggling with how to differentiate all these things from one another; and, more to the point, whether any one of them, as a feature, will eventually allow me to see all such “notes” in a global list of pointers.
In the beginning of that chapter, there is a list of different pros and cons for using linked vs inline notation. For what you are describing, these points seem on target:
- Linked notes can act like bookmarks. Clicking on them in the inspector will whisk you right to the spot in the text where they are anchored.
- Linked notes can be easily viewed together in a collected interface no matter how far they are spread apart in the document. This becomes especially advantageous in a Scrivenings session. A note on page 10 has the same prominence as a note on page 1.
It doesn’t go into detail here, but that list it refers to is of course the dedicated Inspector pane for footnotes and comments. It is worth noting that ⌘G will jump straight to a comment as well as an inline footnote, so long as the inspector list is open. So this basic technique I am describing is not particularly dependent upon using either inline annotations or linked comments. I myself prefer the former, but that’s mainly because, all other things being equal, I tend to prefer the route with less UI in it.