Search/Find in Comments or Footnotes?

I’ve not found a way to perform a search within my comments and or footnotes. Is there a way to perform a search for a string and set up a collection based on that search within my comments and or footnotes?

It’s in Find by Formatting. As far as I know, since it’s not a project search option, it can’t be used as the basis for a dynamic collection.

What " is in Find by Formatting"???

So, it appears that there is no way to perform the sort of search within comments, footnotes, or inline annotations that can be converted to a “collection”??? Is there any sort of meta-data that can be attached to selections or insertion points within a document that can be searched in a way that allows a collection to be produced of that search?

Edit->Find->Find by formatting… You can choose Comments and Footnotes from the drop-down menu and put your query in the text box.

As for metadata, i can’t think of a way, as it’s not possible to attach metadata to anything smaller than a document. As the above demonstrates, comments and footnotes are just formatted text within their document; they have no separate existence. This doesn’t mean it’s impossible, just that I can’t think of a way :smiley: I’ll be interested to see if anyone else has a solution.

I use Inline Annotations with meaningful symbols/words.

To search, I choose Any Word as the Operator filter in Project Search, then Save Search As A Collection.

The usual Edit menu >Find > Find Next (command G) and Find Previous (shift command g) commands can be used to cycle through multiple instances of the search term(s) within a document.

So, is it really true that the only way to perform a search on any meta data that is string or insertion point specific is to use the “find in formatting”?

If this is the case, and I am writing a book, I am forced to work my way through the found set one item at a time, blind to all of the results I have already seen and to those I might see next, potentially thousands of items, sequentially? And to do so again, I must dredge through every item sequentially once more???

Why would there be one way to search in some containers and other ways of searching in other containers? Why would there be one way to navigate the found set for some found sets and other ways of navigating other found sets?

Why would some searches result in a scrollable clickable list of found items, and other search results source you to endlessly hit a “next find” button? Why would some searches be filterable by source container type and others not? Why would the initiation of a search be different in some situations than in others? Why are there so many strangely inconsistent ways one must learn to perform searches?

Is there any way to leave any kind of meta-data (not visible in the main text of the binder entities), that is tagged to user selected strings of text in documents, such that that meta-data can be searched and viewed as a scrollable list of items that when clicked on causes Scrivener to bring up the linked string in question, and for such searches to be converted into Scrivener collections (available in the binder column)?

Thanks, Randall

If I understand what you are asking correctly, no, there is not.

Or rather, there is, depending on how granular you want to make your Scrivener documents within your project.’

As others have stated, metadata attaches to the document in a Scrivener project. (This is because, as I understand it, each document is a separate RTF document in the filesystem. RTF does not include the ability to embed the kind of metadata you are looking for, so it has to be included as a separate document on the filesystem. Hence, each document you see in the project Binder actually represents a number of discrete files on the filesystem.

If you wanted to order your project so that you had one document per sentence, then you could assign metadata per sentence. But that’s the granularity you’re limited to – metadata per document – because of the underlying technology used to implement Scrivener.

Inspector Comments and Inspector Footnotes are part of the main RTF text, and not independent containers. If I search in the main text, I find words that are not only in the main text, but are also in the comments and the footnotes.

For example, I put the nonsense word “razzlefratz” into one comment of one document, then did a project search for “razzlefratz”, with search limited to text only. Project search returned exactly one document, and when I viewed it in the Editor, the word “razzlefratz” was highlighted—in the Inspector comment.

Scrivener makes no distinction, internally, amongst main text, comments, and footnotes; “comment” and “footnote” are formatting spans within the main RTF text, like italics. The fact that they’re displayed in neat little boxes in the Inspector sidebar is for the user’s visual convenience.

There are some workarounds, as have been detailed above. I might add that comments and annotations can be exported separately, File->Export->Comments and Annotations… if that would work better for you.

I realise that you would prefer a different design, and you may want to put in a Wish List request for the same. While I’m not L&L staff (and therefore could be wrong :smiley: ), I don’t think there’s much chance that your request would be implemented any time soon. It would most likely require a change to the project format, and therefore all Scrivener versions (Mac, Windows, & iOS) would need to be updated in order to correctly access projects. The project format seldom changes, for that reason. The last such change was 2016, and the release Windows version finally implemented it in March. In my opinion, L&L are unlikely to change project format again in the next few years.

At issue is how a search is limited (or not limited) to container types. I want to be able to set up a search of a string ONLY within my comments, footnotes, and or annotations (not also including the main text of my finder documents). If I have to use non-sensical words in my comments simply to differentiate those comments from the main text of binder documents, well my life just got far far more confusing and it completely defeats the purpose of separating out meta-data from main text manuscript data. Sure, I could mark up my docs, but that gets in the way of simple reading and editing of my manuscript.

I am using the word “metadata” the way it is defined, not how L&L has used it to arbitrarily qualify certain in-Scrivener containers. The word metadata refers to any and all information that is attached to but not included in the main data of a document. In the Mac finder, a document’s metadata includes its byte count, various dates (first saved, last edited, etc.), user, parent application, etc. In web documents, metadata might include HTML markup, and addressing, etc. The main data is the document as it appears when it is launched, or navigated to in a browser. All hypermedia protocols allow for the attachment of metadata to parts of a document (not only the whole document). Scrivener’s comments, footnotes, and inline annotations are examples of such within document attached metadata. That Scrivener has unfortunately chosen distort the word “metadata” to refer only to an arbitrary subset of its actual meaning only serves to confuse its own customers.

Randall, I massively don’t care how you think Scrivener ought to work. I’ve told you how it works. I’m done.

That’s a pity, since Scrivener uses it the way that L&L defines it, and that’s going to continue to be massively frustrating to you until you accept Scrivener’s definitions and headspace and either find a way to adjust your workflow within those definitions, convince the powers that be to change Scrivener (via the Wish List forum and well-reasoned use cases, not lots of emotional outbursts), or find something else that better matches your mental map of how things need to work.