Kiss: 'ñ' is not 'n'

[EmmanuelMess]

• app version 3.7.11
• android version 4.1.2
• device used Motorola RAZR D1 TV

If I search 'ñ' the results show words with 'n' and 'N'.

[TBog]

What I understand is that you don't want to show results for n when you search for ñ and vice-versa.
What I looked for when I implemented it is exactly this behaviour; it's not a bug imo.
Why do you want to change this?

[EmmanuelMess]

Those are two different letters, it's not like 'a' and 'á'. Why did you implement it this way?

[TBog]

We used the Normalization Forms defined by Unicode, more precisely NFKD.
This normalization technique was started by @alexander255 on 17/08/2015 from what I see on the git history.
In my opinion we do it this way because it's easy to search for with the letters found on an english keyboard. I myself never use "ăîâșț" (letters from romanian alphabet) when i search for stuff, I use "aist"

[EmmanuelMess]

Yes, I understand why search("n") = search("n") + search("ñ"), but not why search("ñ") = search("n") + search("ñ"). What I mean is that if you type "ñ" you clearly have an "n" in the keyboard, but you want only the results for "ñ".

[Neamar]

I think historically, this was done this way because of autocomplete on the keyboard. As a French person, for a contact named "Stéphane", my keyboard might autocomplete with an accent but I also have in my contact book some "Stephane" that would not be returned.

Since auto complete isn't here anymore, I think you have a point -- we should normalize search results, but maybe not the query. I wonder if this might have some unexpected side effects in other languages?

If anyone is interested to look into this, feel free to send a PR :) I might not merge right nozw as we already have a lot for the next release, but this can definitely be tweaked in a better way.

[ntninja]

That long ago, ey? :slightly_smiling_face:

I fully agree with your and @Neamar's observation of the situation. And that changing this probably is a good thing. (Below are recollections on why it was done this way. In short: There really wasn't any reason, it just was easier to implement this way.)

Here some stuff I wrote before I read @Neamar's reply in my mail:
The reason why both search("ñ") ∈ {"n", "ñ"} and search("n") ∈ {"n", "ñ"} is simply because it was easier to implement this way: When processing the list of available apps/contacts/etc each entry description is simply stored twice in memory (the original display form, and the simplified search form). All input text is implicitly converted to search form and then only ever compared to stored simplified search form values, display is always done using the original display form. Between the two a lookup table exists so that highlights are correctly displayed as part of the display form when it actually was the search form that was used during search.

[Neamar]

Closing for inactivity, I'll merge a PR if there is one, but for now the issue is stale.