No matches when LC_COLLATE != C

[eigengrau]

Actually, I just noticed that the changes made in #268 did break something: When LC_COLLATE=C isn’t forced from the enviroment, nothing will match any input, even in cases where it should (so, any character input just yields an empty list). Should rofi enforce LC_COLLATE=C? Though it seems unclear to me why LC_COLLATE=en_US.UTF-8, etc., should break all matching.

[DaveDavenport]

It seems when LC_COLLATE is set

g_utf8_collate_key

Returns pretty much crap.

a results in: 'D��� ' 

[DaveDavenport]

hmm strstr on the collated string not work.

[DaveDavenport]

should be a fix in git (forgot to post last night). Can you test, no need to set LC_COLLATE=C anymore.

[eigengrau]

Nice! Yes, matching works now. Thank you kindly for the fix! Was the problem that collation keys were compared against the (untransformed) input?

As an added bonus, the normalization now allows us to have a binary named è (precomposed è) on the path and it will match against the input è (e + combining grave). Probably a niche usecase, but nice anyhow :)

[DaveDavenport]

collation keys where not suitable for substring matching, only for sorting.
The matching should be reasonably relaxed test³ should be matched by 'test3' too.

Only regex mode now uses it internal matching on the 'raw' string and therefore is more strict.

[eigengrau]

I forgot to close. Thanks for the extra info!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.