So when using the "content: function, semi-colons are given a recognition priority as being just another piece of text?
Yes, the
;
in the search is treated as literal text.
I have updated the
documentation to:
Semicolon (;) delimited lists can be used with any property search function.
Semicolons can be escaped with double quotes (").
Full-text search functions (such as
content:
) treat semicolons as part of the search text rather than as list delimiters.
In my first post, my second example was interpreted as a single string "denfer;rocher;eastern" - a string of 21 characters. I had somehow thought of a semi-colon being a delimiter operation, separating sub-strings within a string.
It is, but only for basic metadata property search functions, like
album:
or
artist:
(where ; is unlikely to be in the property value)
Semicolon lists are are treated as OR lists.
... except when following the "content:" function/operator, for then the semi-colons are subdued(?) to be just the elemental punctuation characters (as in my 21-character string above".
That I find confusing.
Semicolons passed to content: are treated as literal semicolons.
They are not operators.
Semicolons can naturally occur in content, so I avoided allowing semicolons as an OR operator with content:
Here "properties" refers to characteristics of the file CONTAINER, correct?
A property search function is a search function on a basic Everything property, like album and artist.
(any property that is listed under right-click result list column header -> Add columns)
This doesn't include content.
I think that I was considering "content" to be just-another-characteristic or property of a file.
Interally, content is just a property.
So I can understand this perspective.
However, it is treated slightly differently.
For example, you cannot add a content column.
If so, where does SHA fall? Is SHA a property of the container, or is SHA a property of the contents of the container.
SHA functions support semicolon (;) lists.
SHA functions are basic Everything property search functions.
SHA values do not contain semicolons so this works well.
So the Golden Rule would be "use angle-bracket grouping when you want to AND items". Is that correct?
Yes.
This is ideal for content: because the value can contain a lot of text so you'll naturally want to AND multiple search terms.
It doesn't make a lot of sense for properties with small values, like artist because naturally you would just search for the whole text.
For example:
author:"David Carpenter"
instead of
author:<David Carpenter>
So AND is better for long values where you want to AND multiple search terms.
OK. If "Content:" is a function on the CONTENTS of a file (container)
And if "SHA:" is a function on the CONTENTS of a file (container)
might we please have a list of functions such as CONTENT and SHA that operate on the contents of a file container? These functions would seem to be a special category of functions.
I'm working on a content function category here:
https://www.voidtools.com/support/everything/search_functions/#all
You can find this list in Everything:
Right click the result list column header.
Click Content on the left.
These properties all have an associated search function with the same name. (change spaces to -)
