For emoji autocomplete, match insensitively to diacritics

[gnprice]

For emoji autocomplete, if the emoji's name has é where the user's query has e or vice versa, we should treat that as a match. The semantics should match what the web app does.

This doesn't much arise for Unicode emoji, because for all the (small number of) Unicode emoji where a name has a diacritic, we also give the emoji an alternate name by removing the diacritics. It might come up for custom emoji in some realms.

Related issues

• Similar but for @-mentions: autocomplete: In @-mention results, match insensitively to diacritics #237
• Prerequisite: Autocomplete for emoji in message compose #670

[gnprice]

As part of the same work, let's also handle the possibility that the emoji's name has an upper-case letter where the query has lower case.

This one doesn't come up at all for Unicode emoji: all our names are in lower case. But again it might come up for custom emoji in some realms.

[chrisbobbe]

When making the search "fuzzy" like this, ideally we'd prioritize non-fuzzy matches over fuzzy matches. (zulip/zulip#32634 gave me the idea to comment here; we can split this to a new issue if helpful.)

[AshutoshKhadse23]

Hello @gnprice ,
This would be solution for the issue right?

issue.1067.mp4

[gnprice]

From the snippet in that demo, that looks like broadly the right sort of behavior. To tell whether it's an accurate solution would require more detail, like an implementation and its tests.

This is a post-launch issue, though — in fact it's in the M7 Future milestone, beyond M6 Post-launch. So we won't be able to spend time giving feedback on PRs for it until after the app has been launched.

[AshutoshKhadse23]

To get clear idea of implementation I had created a PR.