Searching all documents which have a keyword (or mor than one) is very easy.
But I was wondering how to make more “complexe” searchs like:
- keyword1 AND keyword2 NOT keyword3
- keyword1 OR keyword2
- keyword1 AND Status = Draft
- (text = “xxxx” OR text = “zzzz” ) AND Status = Final
- Notes = empty OR Comment = empty
- Keyword = empty
And many other, which combine together all the tags, metadatas, status, etc.
How to do?
If it’s not possible, that could be an idea for the next Srivener’s upgrade
The “All Words” search operator works like AND, the “Any Words” operator works like OR. Beyond that there is no way of compounding complex Boolean phrases into the search bar in one shot, and there is no concept of a NOT.
If you don’t mind getting your hands a bit dirty with Regular Expressions, you can achieve some more complicated search techniques, but even RegEx wasn’t built for this kind of “meta” searching, it’s more of a character-by-character wildcard syntax than a system for handling chunks of compound data organised into structures, like words. For instance you can kind of abuse its syntax to do a “NOT keyword3” like so: ^(?!keyword3). However that kind of use doesn’t mix will with further declarations (such as keyword1 OR keyword2).
No need to submit feature requests. This has already come up multiple times over the years with the answer that we’ll look into it, but no promises. The pragmatic answer is that Scrivener’s search engine is tuned for how most authors need a search engine to work—it was not designed to compete with database style search engines nor to provide that kind of power. In such a system, blending syntax into the search field is acceptable, but authors may very well need to search for a construct like b[/b], as in the parentheses are an indispensable component of what they are searching for, not a logical grouping.
While you can’t do a complex Boolean in one shot, you certainly can chain together searches to increase specificity.
Thanks for this full answer.
My hope was only to organize the documents, and all the files in Scrivener like I do with Aperture for the picture’s files.
Maybe, if you are an Aperture user, you’ll understand what I mean. Ans Scrivener looks like Aperture (or Bridge or Lightroom too) to tag, sort and find the files.
For example, only combining keywords for a search could help the authors to find the scenes where there is a specific people without an other one.
The other reason for my demand was because I don’t use Scrivener for writing some novels, but only for scientific reports and other same documents.
Oh I certainly understand what you are driving at. I use Lightroom instead of Aperture, and have used many large-scale data management programs in the past. I’m just explaining that Scrivener’s design does not intend to go as deeply into object management as things like Aperture and DEVONthink do, and that if you do need that kind of super detailed and powerful searching for a particular archive of data, Scrivener might not be the best choice for that part of the project. A lot of people use a DTP database alongside a .scriv as their working model, for that as well as reasons of archive scale. The two even integrate fairly well since they both support item-level direct hyperlinking (i.e. you can pull up a PDF from your DTP database from the References pane in Scrivener).
I’m not saying we’re opposed to making the search engine better, and we will be doing so in the next major upgrade—just explaining why it is tuned the way it is. I wouldn’t say that is particularly related to subject matter at all. I don’t write novels, and I’ve never felt particularly limited by Scrivener’s search engine, in fact it’s one of my favourites to the point of pasting things into Scrivener simply to use its search engine. I’m sure a novelist could come up with a reason for using NOTs as well. The question is how often does that really come up in everyday use? I agree it’s a nice thing to be able to “say” to the search engine, but in practice I very rarely need to find a batch of things that are all alike save for one aspect, and when I do need that, the two step method is fine enough.
I.e. the software already has the tools to do what you want I think, unless I misunderstanding something.