Add client side emoji.

[AlMcKinlay]

This replaces all emoji unicode characters with an image of the emoji itself.

Example showing the emoji:

[AlMcKinlay]

So, github seems to be hiding some of the files, because this adds so many files (all the emoji). It's hiding the important ones as well. You seem to be able to view them in the plaintext patch view but not sure how helpful that is.

[astorije]

Holy moly that's a lot of files! I'm sure you can understand I'm a bit defensive on this PR. Here are a few ideas to discuss/think about:

• This is an ideal candidate to the future plugin system really. I know it isn't a reality yet, but that would be great to think of what would be necessary on the plugin system for this feature to be a working plugin.
• 2.6k files! Is it possible to make it a sprite map at least, so that they are grouped in one image and the right area is displayed by CSS (common practice in HTTP 1.1 https://css-tricks.com/css-sprites/, yes it won't be necessary in HTTP 2 anymore, but we're not there yet)
• Isn't there a npm package that does that for us, and then we just take care of bridging Shout with that package?
• This should be made enabled in the settings and disabled by default, in my opinion.

At the moment, I am still opposed to the feature, but if we can make it a plugin (our first plugin?) then I would totally be happy to see this happening!!!

[AlMcKinlay]

Yep, I understand totally about that. It's not an ideal situation, but it's the best I could come up with in the current situation.

• Sure, I mean if you think the plugin system will come along sometime soon, I'd be happy for that. I've added this into my fork and I'm using my fork because I want this feature. It's really annoying not having emoji.
• The problem with sprite map (especially for this many) is that you then require the user to download every single emoji (or if you have multiple maps, then just a number of them) for 1 emoji, and it might be the case that they don't end up seeing many different ones, so that feels a bit overkill. Being individual saves their bandwidth.
• Sadly not. I had a look at a lot of different modules that deal with emoji, and none of them really fit the bill. This one doesn't have a node module, but I could fork it and turn it into a node module, meaning there's less code in the actual repository.
• I agree with having a setting, but I disagree with having it disabled by default. I feel like it's much more user friendly to show emoji characters by default and allow the user to turn it off if they don't want it. Otherwise they end up seeing just a small block if their system doesn't support emoji.

Having said all these things, obviously it's not my code base :-P these are just my opinions.

[Xe]

:+1:

[dgw]

I'm for making this a plugin, simply because it's becoming more and more likely that emoji support will be available on a client. AFAIK iOS, Android, and Mac all have solid emoji support. Windows support is described here: http://caniemoji.com/microsoft-windows/ (site also has compatibility matrices for the other OSes discussed)

Obviously including the actual Unicode emoji characters is the most bandwidth-friendly option of all, for both the server administrator and the users.

[AlMcKinlay]

As said before, totally happy to make this a plugin.

With regards to what this would require from a plugin system, it would essentially just need access to all messages (both at the beginning, when we get the list of initial messages) and also any new messages that come in.

Of course, in it's current implementation, it would require to be able to put tags in the messages and have them render correctly, and not be escaped.

As soon as there's something to play around with in a plugin system, I'll get a plugin written :-)

[astorije]

Hey @YaManicKill, very sorry we couldn't make this a reality. Feel free to edit the wiki page about the package system to add what you think is missing. I'll happily work with you on the package system and an emoji package! I really want to make packages a reality, but I don't want to start without some more design achieved :-)

[AlMcKinlay]

Yeah, that's cool. I'm using it in my fork just now, so happy to just add a package when we get them done. I've added more details to the wiki page.

[astorije]

Great, thanks!