Implicit path queries in a boolean OR yield a match-all query

[intelfx]

This is best illustrated by example:

• beet list /path/to/library/A — works
• beet list /path/to/library/B — works
• beet list /path/to/library/A , /path/to/library/B — lists the whole library
• beet list path:/path/to/library/A , path:/path/to/library/B — works

[sampsyo]

Thanks for the report! This is definitely a bug. I added a unit test for it, which we should enable when it's fixed.

Here's the problem. The beets.library.parse_query_parts function has to play some dirty tricks to special-case implicit path queries. It does this by stripping out path-esque pieces from the query, parsing them separately, and then adding them back into the result of parsing the rest of the query. This worked fine before we added OR queries, but now it (a) leaves blank gaps in the original query, which is the cause of this bug, and (b) adds the path queries back in at the end, which seems messy and might break in the future.

We'll need to rethink how that works. Maybe we need to add a general "implicit query type" functionality to dbcore's query parser.

[intelfx]

It does this by stripping out path-esque pieces from the query, parsing them separately, and then adding them back into the result of parsing the rest of the query.

Hm, why does it need to do such complex things? Isn't it possible to straight-out replace undecorated path-like pieces with proper queries to the path field, in a "preprocessor" manner?

[sampsyo]

Actually, that's not a bad idea! I feel dumb now, but I'd never thought of that, and I don't see any problems with it. Good thinking. ✨