Consider adding a toggle to 'Search'

To clarify, I’m speaking of the search that places a field at top of the Binder when the hourglass is clicked.

It’s a great feature. My only problem with that is it makes the binder contents disappear. If I am searching for WHERE I used the word ‘hotel’, for instance (assume in this example I want to know when that was mentioned in a long-form novel being written), what is displayed is a list of the documents that have that word in it.

That’s great, but the goal is to see where it was mentioned. Unless you name each document by the chapter it is in, there is no quick way to know from the displayed list of documents. The frame of reference, the binder, is hidden. It would be very helpful if the search list appeared differently, possibly in a separate panel, or at top or bottom of the binder, meaning it could be scrolled to view both the search results and the document list, all at the same time.

OK, that’s cumbersome. Also cumbersome is copying the searched word to the clipboard and going back and forth from the binder to a new search using that word, over and over, to find out WHERE the word exists. I find myself doing this constantly as a level of editing.

But I thought of a possible workaround that would make this much easier. As we know, ‘Reveal in Binder’ takes us back to the binder and highlights the selected document in the binder list. OPTION > COMMAND > R will also do this.

Here’s the idea: What if that could toggle? In other words, if the keystroke has been used to invoke revealing the binder, why not allow pressing those keys a second time to toggle back to the search list? That would nearly solve the problem completely.

The beauty here is it would not interfere with any other functionality in Scrivener. That keystroke when pressed a second time would only toggle back if already pressed a first time. Also, it is probably a simple few lines of code to add.

Another idea is to display indicators. By that, I mean display in the document list revealed by search, something that tells the user where that document exists, either by word count location or chapter. The displayed list of docs could be nested inside the folders they exist in which could also be displayed in that list. If a user has the common structure of folders representing chapters and documents representing scenes or beats, that would really work well. It could also be a prefs setting.

What actually happens is the search-based Collection becomes one of several tabs in the Binder area.

Have you tried the Quick Search feature? (Type in the bar at the top center of the Scrivener window, where the current document name is.) It’s not as powerful as the full Project Search, but does give a results list that doesn’t hide the Binder.

You might also find the Outline view helpful, as it will show the full structure of the project in a separate pane from the Binder.


I guess what could be done then is to ‘show collections’, then toggle back and forth between those tabs. Since that involves showing then hiding collections, it is nearly as cumbersome as repasting the search term back in the search field.

A toggle, as I have suggested, using Option > Command > R would be much less cumbersome.

As for Quick Search, when I invoke that it seems to only list documents that have the search word directly in the title of the document, so I’m not sure how that can be helpful when looking for the word in the text itself. I guess I might be doing that wrong, but one would think typing in a word would reveal a list of docs with that word in the text, instead.

Might be time to go back to the tutorial.

The outline view is indeed helpful, but I can’t find a way for it to display the docs that contain the word searched for.

My point about the Outline view was that you can use it to show the full project hierarchy, as in the Binder, when the Binder itself is hidden.

You can also use it to show a Collection, though. Just select all the documents in the Collection, then go into Outline view.

For me, Quick Search shows results with the search term in the title, in the synopsis, and in the body text. Try searching for “documents” in the Interactive Tutorial project, for instance.


That does work. I have no explanation for why it didn’t work that way for me earlier.

But I can also think of a possible improvement:

Assume you have done a search. Now, when you hover the cursor over a selection in that list, it would be very helpful if the hierarchy of where that is located would appear (not in the list, but as a separate field, the way Tool Tips works in the Mac OS). Even more helpful would be the ability to then navigate to a level above in that hierarchy, such as the folder that document is in, which would leave the list intact yet display the selection in the editor.

Think about when you have a window open in the Finder and click on the folder icon at the top, how it reveals the hierarchy and allows navigating there.

This would be helpful in moments where one questions “What chapter did I reference X in?”, for instance when one is trying to make sure they didn’t reference something that wasn’t explained until a later moment in the text, which is an author ‘subjective view’ problem regularly in writing fiction. This would allow us to see where that reference actually is (what over-nested folder contains it) to determine if the story order makes sense or not.

For instance, if the folders represent the chapters by name, which I understand from Keith’s research is a very common way to structure the binder, we would know instantly which chapter the document was actually in, and could even navigate there directly.

Without that ability, what is displayed is a list of documents, but there is no reference to them other than their titles, and no real reference to what folder they belong to, just the list in serial order, which often is not nearly enough to answer that above question, so if one is looking for a particular reference, it’s basically pot luck finding it. Adding the hierarchy in a Tool Tip window would provide that frame of reference that is missing.

See also