Is it possible to create a doc a folder that will contain links to various words or paragraphs throughout the whole document?
So a list of exceprts in a text doc which are hyperlinked (and ideally reference which page they are linked to) and when you click them you go to that other text file within the larger script?
My custom tags look like this:
[= Űž]
The “=” being there as a common character to all my tags and inline notes, so I can find them all globally.
Where Űž would be specific to one thread.
I keep a record of what’s what in a dedicated document, that I can quickly access using Project bookmarks.
If you wish, you can also apply a character attribute style to them, so that you can automatically have them all removed from compile without having to worry about it.
→ Add that style to your compile format, and check “Delete text of this style”.
In your case, you could make a list – just like you described, except you’d need to populate it manually -, and perhaps then use numbers instead, if you think you’ll end up with quite a lot.
[=01] She falls off the train – link to document → then use find inside that document. (Searching for =01 or the whole tag, whatever.)
[=02] Her car breaks down – link to document
[=03]
etc → Creating a blank list in advance could spare you using the same tag twice by mistake. (It also has the advantage that you could have the character attribute style already assigned to them, where you’d just copy/paste them (or even drag and drop from your list) where needed, in the editor, afterwards.)
A bit tedious, but functional.
Of course, having such a feature in the app would be by far better.
Aren’t you essentially describing the project search feature—and for a persistent form of that (a “doc” if you will), a search that has been saved as a collection?
What you’re describing is pretty much how it works:
Click on collection with your word search.
List of documents appears on left, select where you want to go and hit F3 in the main editor to scroll to the first match.
Alternatively, right-click on the editor header bar icon and use the Go to Collection â–¸ submenu to load the list into the main editor itself, where a Scrivenings session gives you an aggregated list of all results, with again of course F3 to help us get from one spot to the next.
I think any improvements to that approach would be better developed into the existing tools, like providing better contextual results, instead of having a whole different feature that almost does the same thing, but differently, if that makes sense.
I think the user is asking for the same thing as other users who (justifiably) ask for in-document bookmarks.
The thing with search is that (among other things) :
you don’t get a list of corresponding excerpts of the concerned documents’ body text.
you need to know what word(s) to search for
who says all desired references have a word in common? (Without a common tag, it is unreliable; thus my manual tagging method.)
Yes, as noted that’s the main missing component from the original question, and what I mentioned as being something better added to search results. I think contextual snippets would make searches a lot nicer and more modern.
I guess not knowing precisely what you’re looking for could be a problem at times (though that seems the sort of thing with a human solution rather than software), but they asked about building a list of word matches, so I think in this case that isn’t an issue, but maybe I’m reading it incorrectly.
No contest there, that’s a great idea, and how I target phrases directly where it is important to do so. Some people think of this is a less useful system than linking, but I personally would go on using an approach like this even if such links could technically be added to the software (unfortunately they can’t, which is why this has been something on the “no” list for as many years as Scrivener has existed).
This is how systems such as Obsidian, Zettlr and others work as well—they insert a text code at the point you want to link directly to. What they do better is hyperlink directly to it, but these things are built in a different framework than what we have to work with. They are HTML behind the scenes, rather than RTF, and HTML has native and simple support for putting an anchor anywhere and all web kit views natively handle the problem of loading a resource and then scrolling to the right spot.
We can do that in Scrivener, using the system I describe in that linked page, it just takes a small extra step of copying the target marking into Quick Search. When activating a result from that tool, it scrolls you to the right spot, effectively doing what a direct link would. For those more inclined toward keyboard use than mice, it’s even better than most linking solutions, which require grappling with a mouse to get anywhere.
Ever since I first red that it can’t be done because of the coding on which Scrivener is based (and I am not complaining here, having my own functional solution ) I keep thinking of a style that has no value whatsoever other than being a highlight box.
No character attributes, no paragraph formatting, no effect on compile… just a box.
From there, things look a bit more possible, no ?
Maybe, though the solution I’ve always felt would be most natural would be a right-click “Copy link to comment”, or something along those lines. The code for scrolling to a comment’s highlight already exists. The problem as I understand it though has less to do with marking the spot, and more to do with the hyperlink side of things. We can say what to load, but not where to load within, like you can in an HTML link: target_resource.html#specific_spot.
Why not just use Quick Search? It already does all of that, though without cross-purposing the Ctrl+F tool. Selecting your mark point from the Quick Search list is effectively all three of those items in your checklist rolled into one Enter key trigger (or Alt-Enter to load the reference into a split instead).
In many cases, if your markings are single-ended and unique, you don’t even have to arrow down to the right result. It pops up pre-selected the moment you paste the marker into the search field.
Sorry, I think we’re talking past one another at this point then. Quick Search (not project search) is 100% compatible with and greatly augments the marker tactic. It also provides contextual snippets from location of the marker, resolving point one. Point two is completely irrelevant because we’re using it to jump directly to a marker, not word searching.
I describe this in much greater detail in the linked post though, so maybe give that a skim before dismissing the tool entirely. It’s super useful to those using markers as jump points.
Yes, creating a Glossary using document links is possible. Creating an Index with page numbers is a different story.
I’ve described the procedure in the book Mastering Scrivener, because it’s quite a few steps to create on: in short you create folders and documents with a Section Type, select a term and link it to a document with a description and link it back to the original location of the term. Sort items in subfolders and naming folders alphabetically. Create a Section layout, making sure the items don’t end up on separate pages.