Adds support for skin variants

[benedikt]

This pull request adds support for skin variants which will land in iOS 8.3 and OS X 10.10.3
To get this working I had to add some additional methods added to EmojiChar and update the emoji.json

I'll happily adjust the code should there be any issues with it.

Thanks for building this in the first place. This literally saved my sanity today.

[mroth]

This is fantastic, thank you for doing this! I will try to review soon.

[mroth]

Since the number of possible skin variations is constant (either N>1 or 0), this method name should probably be plural, e.g. skin_variations?.

[benedikt]

That was my initial thought as well, though there's the variant? which also checks if there's > 0 variants. So I decided to match the name.

[mroth]

Added some line notes.

[mroth]

Some additional questions:

1. Do you have a device/OS that generates the new emoji and have tested that we properly decode them? I don't think the emojidata.json project is unit tested so I want to make sure we aren't taking for granted as source of truth something that isn't correct.
2. I think we should probably figure out how to represent the notion of preserving the skin tone of an emojichar once we decode it. Going from unicode string -> EmojiChar representation it previously didn't matter if we preserved the notion of whether it was variant encoded or not (since those variations were not semantically relevant), but I imagine for these once we decode we will need to have the Object have some awareness of it's "active" skin encoding if present, which would be carried forward into the default render behavior. (Since a number of applications use this library in a unicode -> object representation -> unicode pipeline).

Thanks for bearing with me on this, this actually represents a very large upgrade for EmojiData (again, thank you!), so we need to make sure its bulletproof before pulling in and subsequently porting the logic to other platforms.

[mroth]

For these, I like to mock what we would actually get when parsing emojidata library, so although its going to be verbose we should do this with the full identical list of variations we get for an ear when importing the vendored data.

[benedikt]

Would that apply to the other EmojiChar instances as well?

[mroth]

@bendikt Apologies, I finally have time to get back to this. I appreciate massively the work you've done. 🙇

I've re-reviewed this in more detail now.

My thinking in terms of where we would go from here:

1. Some sort of an active_skin_variant property in EmojiChar (defaulting to nil I assume?), which would be taken into considering when render-ing and properly detected during a scan decode. Unlike the unicode variation selectors, these skin tone variations have semantic meaning that it is important to preserve.
2. Update to the latest emoji-data json with the iOS 9.1 emojis (Optional but maybe easier to do in one shot)
3. Do some baseline performance benchmarking to make sure nothing went crazy with all the additions (I can assist with this).

Is this something you'd be willing to take on? (I promise I can be more active in reviewing now! Including pairing if helpful).

[dacort]

Just a heads up re: updating to latest emoji-data json.

There appear to be characters in there that are regular expression special characters and lead to this error when creating FBS_REGEXP:

RegexpError: target of repeat operator is not specified
from lib/emoji_data.rb:136:in `initialize'

I'm guessing it's the keycap_star character that renders as an asterisk. Using Regexp.escape on each char when generating the regular expression seems to alleviate this issue.

FBS_REGEXP = Regexp.new(
  "(?:#{EmojiData.chars({include_variants: true}).map{|ec| Regexp.escape(ec)}.join("|")})"
)

More than happy to create a PR for updating the json with this fix in the near future.

[bhollis]

You might want to look at Regexp.union as well.

If there's any way I could help with merging in this and #4 so we can recognize new emoji, I'd be happy to volunteer!

[mroth]

@bhollis if you want to give it a stab, I'd be grateful! I've been pretty tied up with a number of other projects and this has been lower priority.

(We can chat on IRC or whatnot if that would help coordination. I'm typically on freenode in #emojitracker.)