Query words are case sensitive

[milnak]

Problem

Running this command in verbose (-vv) mode:

$ beet list --format '"$title" on "$album" by $albumartist ($length) ($year)' albumartist:kenton 

works

but this doesn't:

$ beet -vv list --format '"$Title" on "$Album" by $AlbumArtist ($Length) ($Year)' AlbumArtist:kenton
(venv-beets) jeff@nuc:~$ beet -vv list --format '"$Title" on "$Album" by $AlbumArtist ($Length) ($Year)' AlbumArtist:kenton
user configuration: /home/jeff/.config/beets/config.yaml
data directory: /home/jeff/.config/beets
plugin paths:
fetchart: google: Disabling art source due to missing key
fetchart: lastfm: Disabling art source due to missing key
Sending event: pluginload
library database: /mount/usb/Music/beets.db
library directory: /mount/usb/Music
Sending event: library_opened
Parsed query: AndQuery([SubstringQuery('albumartist', 'kenton', fast=True)])
Parsed sort: NullSort()
"$Title" on "$Album" by $AlbumArtist ($Length) ($Year)
"$Title" on "$Album" by $AlbumArtist ($Length) ($Year)

Led to this problem:

no query matched. Should query fields (e.g. $year) be case insensitive?

Setup

• OS: ubuntu
• beets version 2.3.1
• Python version 3.12.3
• Turning off plugins made problem go away (yes/no): no

[wisp3rwind]

I'd argue that this is by design. What's the advantage of making this case insensitive?

[milnak]

what's the disadvantage of making this case insensitive? Would one expect that '$Album' and '$album' would be treated differently?

[wisp3rwind]

what's the disadvantage of making this case insensitive? Would one expect that '$Album' and '$album' would be treated differently?

I'd appreciate if instead of simply dismissing the question for your rationale by just asking "why not?", you'd actually argue the value of case-insensitivity. (e.g. how this might be common in other tools, why were you expecting this to work in the first place?)

That said, yes, coming from an in general case-sensitive background of Linux file systems and modern programming languages, I wouldn't expect these terms to be case-insensitive. They really are more like variable names rather than free-form language.

I don't think the documentation suggests in any way that upper case should work. If anything, beets might provide a warning about non-existing queries (but that might not be completely straightforward to set up, given things like flexible attributes, which might only be set for some items).

I'll move this to a discussion, I don't think this should be done unless there's really a wider interest.

[JOJ0]

I agree that this should not be done. Since what we essentially do here is "some kind of easy programming / variable replacement". It is not common in any programming language nor in any query language that things like that are case-insensitive. It simply is documented as being lower case and that is what the user / the pattern programmer should follow.

There might be cases in business / open source / whatever software where things are case-insensitive but very often they are not. maybe take an example from business software like Atlassian Jira - they have there own query lanugage but if your write and it won't work, you must write AND, because that's the way the keyword is defined and that is how it is documented.