(Update: replaced “keyword” with “search term” for clarification)
Searching with a search term in “All” searches, text, title, synopsis, notes, custom metadata (as appropriate), etc.
When a search result is selected a document appears in an editor - and if the search term was found within that document it is highlighted (NB it would be nice if there are multiple search terms for them to be highlighted in different colours, but that’s another thing). That usually makes it easy to identify - but if the document is long I can always search within it to find the search term(s).
However, if the search term is found in notes, or synopsis, or anywhere outside a document it can be very hard to work out where it is!
Requests:
Consider ways in which the search target (text, title, etc.) in which search term(s) were found are listed next to the Search Result document title (1-2 char labelled columns of indicators for major locations such as TE[xt[, TI[tle], N[otes], S[ynopsis]…)
Highlight hits in locations other than documents to the maximum extent practicable, but especially synopsis and notes.
Where there is >1 search term, highlight the various terms in different colours
(If a “hit” only occurs in one of title, text, etc. , where sensible make selecting the result show the containing UI element (e.g. panel containing notes if not already visible) )
Rationale: I just did such a search and spent ages trying to find the hit, which was eventually found in lengthy notes. Inability to see/find resulting hits then leads to other (time wasteful, duplicative) ways of identifying things.
Obviously not a critical capability, but it would be nice.
One thing that could be done as a Scrivener feature is some automatic tagging/keywording being applied for each type of binder item.
For now, I think it should be doable/worth it to make a pass to add those keywords yourself, a few minutes of grunt work to arrow key down through your project and add “notes” “text” “ect” to each binder item.
Once done, you can at least exclusive &and search by category to quickly check and narrow it down.
Normal search gets too many/hard to find result → [ctrl + click] the keyword & [type keyword] to start eliminating possibilities.
If it’s more appropriate for your project, you can also use keywords for specific branches of your project, so instead of/in addition to the “document” keyword, you can add a “second draft” kind of keyword.
I just replaced “keywords” with “search term” above for clarity since the issue is far more general. If I were just interested in a limited set of keywords then I might follow your suggestion, thx.
No reason the two systems need to be separated to begin with.
Keywords becomes a “tag tracker” UI, or “quick tags”. You still see and assign ~keywords as before, but in effect every searchable word of text is also a “tag”
Can add keywords/tags to mark binder items, ect.
Unifying the two searches would be pretty huge from a functionality standpoint.
It looks like the primary section of the manual about the search functionality starts on 215
Combining search terms starts on 222.
I don’t think either of our exact use-cases can be done. The UI for “Search In” can only select one option at a time AFAIK. Can’t do something like [keyword]:“character name” “unique text”
(I might fiddle more with trying to have a keyword or two filter results of an all text search.)
but the example of date restriction, how long ago it was written/edited might be useful.
Alt-hold-click the magnifying glass icon, then (Alt still held) in the search fields list.
The UI is a bit messed up. It’ll close on you (Windows), but still, do it in repetitive steps: it works.
Vincent coming in w/ the not-in-manual key functionality.
Turns out this alt-click selection (even though ctrl-click multi select is used elsewhere?!) has another requirement/trick. If you try to include “All” in your “Search In” it will override and deselect any other category. You can only multi select others. Which is fine, as long as the UI informs the user!
Just give us the syntax and keywords to construct the searches manually please! Functionality like that should never be GUI-only.
It was a bit of a facepalm when I realized that, yes.
Any form of UI distinction to separate or signify the difference between the selections would be much appreciated, but that degree of care is rare today.
Something like an indentation for all the sub-fields after All, a horizontal line beneath All, or even a downward pointing carat in front of All (like an expanded folder) to cosmetically communicate the below elements are sub-units of All.
Nothing’s perfect, room for improvement, ect, ect.
. 
