[vanniktech]

No description provided.

[vanniktech]

@rubengees I don't remember but do we have this treatment that I added anywhere? For instance:

IosEmoji(
  unicode = "\u203c",
  shortcodes = listOf("bangbang"),
  x = 57,
  y = 39,
  variants = listOf(
    IosEmoji("\u203c\ufe0f", emptyList(), 57, 39),
  ),
)

If you're searching for bangbang you want the ‼️ emoji. However, this is the "\u203c\ufe0f" and not the base one, the base one renders really ugly: ‼, where as you almost always want ‼️.

It almost feels like we should not have support for \u203c at all, because it's just a normal unicode and not an actual emoji. And instead only:

IosEmoji(
  unicode = "\u203c\ufe0f",
  shortcodes = listOf("bangbang"),
  x = 57,
  y = 39,
)

[rubengees]

Hi, I also don't remember the details, but it is caused by #1087. This question has a good explanation on the variant selectors: https://stackoverflow.com/questions/38100329/what-does-u-ufe0f-in-an-emoji-mean-is-it-the-same-if-i-delete-it.

I think we only want to recognize unicode that actually renders as colored emojis so in the case of ‼️ we should only accept \u203c\ufe0f. This can be done by updating the generator to just use unified and drop the non_qualified branch.

That will of course be a breaking change since we will stop to recognize text-only emojis (like the !! in your example). I'm not sure if there are any other implications as well. It would be more correct though I think.

[vanniktech]

@rubengees thanks. Did this in #1276