mirror of
https://github.com/zulip/zulip.git
synced 2025-11-05 22:43:42 +00:00
dc6e9df43a
For example, if a user's name is "Simon Peyton Jones", we'll already match that name on the queries "Pey" or "Peyton", as well as on "Simon P". We should do so on "Peyton J" or "Peyton Jones", too. Similarly, if the user is looking for an emoji of a face in the moon and they start by typing ":moon", we'll show them both 🌝 "moon face" and 🌚 "new moon face", along with some other moon-related results. If they go on to make it ":moon " or ":moon f", though -- as one very naturally would in order to eliminate things like "waxing moon" and "moon ceremony" -- then we mysteriously eliminate 🌚 "new moon face". Instead, the query "moon f" should match both 🌚 and 🌝. Found this while comparing the web/shared implementation with the mobile implementation of emoji search. The new behavior here reflects what we already do for emoji search in mobile, both in the compose box's typeahead and in the add-a-reaction screen. The existing behavior here seems pretty annoying, so fixing it will be part of switching on mobile to the shared code (zulip/zulip-mobile#4636) without regressing the user experience. The current behavior was introduced, more or less, in 245d65eb9; then revised in5edbcb87fto make the logic more clear, and a fix made in542f4766d, all 2018. The PR thread was #8286, following issue #8279. The old behavior before those changes was pure substring matching, plus a trailing space was ignored (which is the part the issue was about.) None of the discussion touches on this question; as far as I can tell, the fact that "Peyton J" doesn't match "Simon Peyton Jones", nor "moon " match "new moon face", was entirely an unintentional side effect of those changes.