I have noticed something strange
I now create a document with the title “1” and leave it visible in the editor.
Then I search the project for documents that were created at least one month ago (cdate:<1m). As expected, document “1” does not appear in the search results.
Now I add two words to the search. “this” and “test”.
And suddenly the words are also highlighted in the document not found, which is visible in the editor.
That surprises me. Although the document should be excluded from the search by the date, Scrivener still searches in it and doesn’t show it at the end?
Is that how it should be? Why searching in documents that have been explicitly excluded from the search?
Aren’t you currently searching documents that are less than one month ?
I interpret < as: Search documents that were created a month ago or earlier. This is why “1” is correctly not displayed in the search results. Or am I making a mistake?
Well, I am not sure about the > or <, but aside that, if you are searching in text and have not entered any, perhaps that’s why it doesn’t show before that point. (?)
In math language, date<1m should mean less than a month old. (date – smaller than – 1m) (1m – bigger than – date)
Doc “1” does not appear in the search results even without text. Which is correct. It was created today.
Conversely, it appears when searching like this: cdate:>1m
The question is: Why is the document being searched for even though it is not supposed to be found?
You are looking for your gloves in a chest of drawers with 4 drawers. You are told that the gloves are not in drawers 1 and 2. Of course, you then only look in drawers 3 and 4, but Scrivener still seems to look in all drawers.
Well, no. You are asking it to look in all drawers. The date is a condition, just like the words you’ve added.
To take a guess I’d say that (perhaps) files that haven’t yet crossed midnight, being zero days old don’t somehow register ??
Mm, I don’t know anything about programming and I don’t know how other apps do it. But common sense tells me that it doesn’t make sense. The basis of the documents was found with cdate. If words are now added to the search, only the documents already found need to be searched. Others are out of the question because the cdate is wrong, no?
Add you test words to a document that is 2days<cdate<1m and see.
(Older than 2 days but less than 1 month)
One that should be left out of the search but that wasn’t just created.
Sorry, my little son is ill … I’ll take a closer look later. But anyway, Scrivener highlights locations/words in documents that are not shown in the search results. Why is that? Isn’t that just using up resources for nothing and make the search slower?
What happens if you swap the order so that the date condition is first?
Is that a trick question? Then nothing happens! cdate and mdate must be at the end so that Scrivener searches.
However, that could be part of the explanation. If the date could be at the beginning, Scrivener could limit the search for the words to these documents. The words entered afterwards would only be searched for in the documents with the matching date. Is that what you mean?
But this still does not explain why Scrivener highlights locations / Words in documents that are not displayed in the search results
I’m thinking that the date condition is acting as a filter on the results already found by the text search.
I would find this more logical: The date forms the new smaller and closed quantity of Docs in which the words are searched for.
At least that’s how it seems to work with other “filters”. If I limit the search in the menu to “Notes”, Scrivener does not also search for the words in other fields and highlights them in the background.
I’m speculating here, but it might have to do with the order in which things are parsed. The search options from the menu are “seen” first, then the items in the search field, in order, then the date “filter.”
In any case, I agree that this is unexpected behavior.
Why do you have to speculate? You could ask someone who knows and then share what is true … forget it, it’s ok. This is where my outdated work ethic shows.
… It’s your app. I’m only allowed to buy and use it if I want to.
I could and I am. Just because you don’t see something, that doesn’t mean it isn’t happening.
If I could read minds, I would certainly earn my living with it. Until that happens, I’m dependent on you to tell me: I’ll find out and get back to you.
To answer the original question, there is, as it stands, no deeper intent in what gets highlighted in the editor, other than these two conditions:
- Is the text in the editor.
- Does the current search include Text in its parameters.
You can repeat this test using another one that excludes trashed items, and look for words found within a trashed document, then navigate to it with Quick Search while the search sidebar is open (or I suppose leave it open before searching like you did, and then not click on any of the filtered items in the sidebar).
Is that useful? Maybe sometimes.
Ah. Which means that someone who uses the Project search when they really want the Document search will still get useful results.
Yeah, or as a Find substitute on purpose, for its global highlight, which Find doesn’t do.
Another scenario where it might feel odd if it didn’t, is if you’re using search for its capability as a kind of passive word highlighter, to make overused words pop out. You might leave such a search open for hours while editing and writing, and can go on to use the outliner/corkboard or whatever and write new sections, while having these words automatically highlighted as you type (actually, that one is not as useful on Mac since it only refreshes highlights on load rather than while typing, but that does work on Windows). Once you type the word and refresh the search it would show up, but not before then, yet it would be odd not to highlight under those circumstances just because you haven’t refreshed search yet.