Problem filtering by year

[amachronic]

Looked at it poked at it came away with:
Above my pay grade

(math pays off sometimes I guess lol)

But seriously, instead of an ad-hoc operator to solve this problem (which won't address the general issue) you just need to move the "filter clauses" to a separate group.
I call them filter clauses because tagtree wants them to be filters but the tagcache can't support that.
https://github.com/Rockbox/rockbox/blob/master/apps/tagtree.c#L1486
instead of prepending them to the main clause group with tagcache_search_add_clause like tagtree is currently doing there, you can create an entirely separate clause group in the tagcache, add a new function tagcache_search_add_filter_clause to add stuff to it, and evaluate that group in addition to the main one.

I think that would mean adding another check_clauses() above the current one here
https://github.com/Rockbox/rockbox/blob/master/apps/tagcache.c#L1382
like so

Code: [Select]

            /* check filter clauses first */
            if (!check_clauses(tcs, idx, tcs->filter_clause, tcs->filter_clause_count))
                continue;
            if (!check_clauses(tcs, idx, tcs->clause, tcs->clause_count))
                continue;


That will solve the problem in this case and most simple cases. A more general solution will probably require an AST to represent the query expression and that's a lot of refactoring.

[Bilgus]

Sounds to me that you have an idea, feel free to run with it.

Edit--
Filters can only be used with entries you can point at with a seek index into a db.tcd, virtual tags and number tags dont index into a tcd file AFAIU

Further I'm unsure how you decide the users intention without adding another operator or parens

[amachronic]

OK, I'll put this stuff on the bugtracker then so it isn't forgotten.

re. the user's intention: right now the ANDs always bind more tightly than ORs so there is no ambiguity, it's just that tagnavi docs are very unclear about this, and it is too easy to get confused. Supporting parens would be better of course, and tie in nicely with AST-based queries.