This is interesting to me, because I actually don’t think I’ll use date ranges very much. I’m much more interested in searching by people and keywords, especially in combination.
Obviously neither of us is right or wrong, but it does underscore that there are lots of different preferred use cases.
Thanks for those links!
I thought non-ISO-formatted dates would be neat, too, and did a bit of looking for a date parser that supported internationalization, but (like most of npm), were either English-only, had no tests, had been abandoned, or all of the above.
I think just a could regexs would get year, month, week, and day parsing. Here’s a google sheet: please ask for edit access if you’d like to add a language or other examples.
Would tag:/a/b/c suffice (where /a/b/c is the entire path of the tag)?
Just as more feedback… I do want to deal with date ranges a lot, but personally never seem to use the “natural language” type date formats (last week, etc.). Maybe it’s the programmer in me that finds them too ambiguous (or I’m just too old :-)).
Anyhow, I certainly don’t mind if they are there for folks that like them, I can see the use, but just to toss in my 2 cents…
Sorry, I didn’t explain better about tags
What if I want to find tag:/a/b but I don’t want to include tag:/a/b/c or any other descendants of tag:/a/b
Real use case example kw:dog but you want to exclude kw:dog/Fido, kw:dog/Rex etc. So basically, you want to find only unknown dogs.
Hope this example explains my concern better
I’m also a programmer and yyyy-MM-dd is the only thing that I prefer most of the time, but as your product’s supposed main audience is non-IT, I assume date:"last summer" is more preferable to type than after:2020-06-01 AND before:2020-09-01
BTW, relative dates you can find even in a very IT stuff
--date=relative
Ah! I already added operators for date terms: perhaps tag:=/keywords/dog means only look at that tag, and not match descendant tags: would that work?
Edit 20210410: deleted the remainder of the post, as it has been superseded by the documentation.
I think this example is not accurate enough as
fs:=a/b/c matches /photos/a/b/c/file.jpg assuming that /photos is a single root of your photo library. But I think you support having multiple roots so it will also match /other/a/b/c/file.jpg and that makes := to mean what it actually isn’t.
Moreover, with that logic how can you find fs:=photos/a/b/c when you want to filter only the photos root folder? How to make the syntax not ambiguous so it won’t mistakenly include /other/photos/a/b/c/file.jpg?
Ah, good point, I’ll add these as examples.
The solution is to provide an “absolute path” to the tag your want to match.
tag:=foo/bar means match all assets directly associated to tags that end with foo/bar. I think it will be helpful for who:=michael to only match first names.
tag:=/foo/bar means match all assets directly associated to tags whose path exactly matches /foo/bar. You have to include the entire path.
So to avoid files in /other/a/b/c/, you’d use fs:=/a/b/c.
Note that the fs: search terms currently hit the tag fts index. I’ll be adding an asset fts index as well, which will include title, description, and metadata terms at some point in the future.
Then we need an example how to use absolute path on Windows that has \ path delimiter
And if := actually means ends with tag so maybe you should consider changing syntax to something like old school jQuery style $=
https://api.jquery.com/category/selectors/attribute-selectors/
I guess I could change it to
:= means “tag exactly equals”, and:$= means “ends with”?In that case, is tag:=a/b/c equivalent to tag:=/a/b/c?
Right. I’ll add a note that windows users must convert all “\” to “/”.
So it’s fs:"C:/Folder with space/a/b/c"?
Also it’s a bit unclear about fs, description says we query asset’s pathname, but don’t you think we should also be able to query filename? Maybe you should rename fs to path and also add an ability to query filename? Or maybe even fullname that will include both path and filename?
Also I think it’s essential to add a Lightroom’s killer feature where you can search any text and it will find all the assets that include that text in any tag. So you type something like text:michael and it will find everything including /photo/michael/123.jpg, /photo/a/michael.jpg, who:michael and even city:michael
Edit: 20210410: Yes. This query will work.
YES! This is absolutely how I want “filterless” queries to work.
Instead of text:michael, though, it’s just micheal, just because that’s going to be simpler to type. I don’t expect many people will get into filtered queries and operators: I expect them to want to type “beach sunset” and get something reasonable.
After thinking about it more, I feel like := and :$= look too much like line noise.
I’ve just updated the examples on PhotoStructure | How to search your PhotoStructure library and hopefully that clarifies my thinking.
I realized that fs:/TERM tags could replace mountpoints pretty easily, and then I think that’ll handle @mnaoumov 's issue.
The alpha with this feature has shipped, so I’m closing this topic to release everyone’s votes.
You may need to shift-click reload to see your new vote count: please make sure you vote on the next-highest feature you want!
If you have other comments about search, if it’s relevant to these topics, post a reply there, or open a new topic describing the bug or idea:
(fwiw, next on my plate is album creation, sharing, delete, and face detection, but I’m not set on what comes after that: it’s up to y’all).
