Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#44816 - [ncmpcpp] 0.6.3-2 Unicode searching in not case-insensitive

Attached to Project: Community Packages
Opened by Glenn (grepfor) - Saturday, 02 May 2015, 15:34 GMT
Last edited by Levente Polyak (anthraxx) - Sunday, 03 May 2015, 19:34 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

See report filed on developer's bugtracker:

http://bugs.musicpd.org/view.php?id=4357

Response from developer was:

'As long as boost was compiled with ICU support, regular
expression searching will be unicode aware."

So his implication seems to be that the distro is at fault, i.e. boost libs are not
being built with ICU support. I have no clue how to even determine whether the boost
libs were built with ICU or not, so am not pointing any fingers, just looking for
assistance in sorting this out.


Add'l info:
Environment in which this behavior was observed has $LC_ALL=en_US.UTF-8, if
that is relevant. (I would hope it would not be relevant, because the
user's locale should not affect the search behavior over character sets in
other languages....)

Thanks.



This task depends upon

Closed by  Levente Polyak (anthraxx)
Sunday, 03 May 2015, 19:34 GMT
Reason for closing:  Upstream
Additional comments about closing:  problem is within upstream and confirmed to get fixed in future versions 0.7.x
Comment by Levente Polyak (anthraxx) - Sunday, 03 May 2015, 16:26 GMT
Our boost-libs are already build with --with-icu so that shouldn't be the problem. I have checked it with non-cyrilic unicode chars and that works well (it is properly case-insensitive) so it may be related to cyrilic maybe.
Could you verify if the search works properly for files with ö and Ö?
Comment by Levente Polyak (anthraxx) - Sunday, 03 May 2015, 17:14 GMT
I have also tested it with Cyrillic characters and it seems it is working as long as you search mode is "Match if tag contains searched phrase (no regexes)", if I search with "(regexes supported)" then it is not working.
I have tested it with the Cyrillic character И and и.
Comment by Glenn (grepfor) - Sunday, 03 May 2015, 17:42 GMT
I agree that it works if the search mode is "no regexes", but the search string used when this issue arose didn't contain any regex characters, only plain (Cyrillic) alphabetic text, and the search was done in Mode 2 ("regexes supported").

So it sounds like the next step (for me, I mean) is to go back to the developer, as there seems to be some confusion as to what the phrase "Match if tag contains searched phrase (regexes supported)" actually means. Or just a plain bug in that mode.

Please leave the ticket open for now, until I hear from the developer. I'll post here when I hear back from him, and close the ticket if he acknowledges the problem is on his end.

Thank you for your detective work on this.
Comment by Levente Polyak (anthraxx) - Sunday, 03 May 2015, 18:53 GMT
according to the upstream ticket this got implemented in 0.7.x (which may take a while until its released).
So until 0.7.x it will only be possible to search in a non case-insensitive way for UTF-8 chars if used with the "no regexes" mode.
Comment by Glenn (grepfor) - Sunday, 03 May 2015, 19:15 GMT
Yes, saw your ticket on the developer's site, and he just replied to mine as well.

I'll close this ticket, clearly not a problem here.

Appreciate your time and assistance, Levente.

Loading...