Smilie/Emoji Short-Code suggestions should prioritize local smilies over emoji

[Kevin]

Affected version

2.2.7 PL1

To clarify, when you start typing in a 'short-code' for a smilie or an emoji in the editor a pop-up box appears with similar suggestions. When the similar suggestions are shown the local defined smilies should be shown first over emoji that have same defined short-codes.

To demonstrate, I have a local smilie defined with the following short-codes:

:)
:-)
(:
:smile:
:smiley:

The image file for the local smiley points to a distinct version of the smiley face versus the generic yellow smiley face.

When I start typing in :smile the pop-up suggestion box shows the :smiley: suggestion of the generic yellow smiley instead of my locally defined :smiley:. If I continue typing in the full :smiley: then the local defined smiley shows as wanted.



I was kinda' hoping that even though the wrong image was showing in the suggestion pop that, after saving the post, that it would be smart enough to use the local :smiley: but that isn't case, instead of inserting the short-code shown on the pop-up it inserts the unicode.



Now if I toggle the editor to turn BB code off then the pop-up box does insert the short-code instead of the unicode and saves it that way, the result then is that even though the wrong image is shown in the suggestion pop-box that the correct image ends up getting displayed in the post.





Maybe if the pop-up box is not that easy to work around then at least an option that the short-codes are inserted into the post all the time instead of the unicode? I know that'd make me happy at least.

 

[Kevin]

To add to the mystery, it seems to work if the short-code in question is the first line of replacements.

For example, changing it to the below makes :smiley: work as expected but then :smile: breaks. So the issue seems to be more-so related to the ordering of the replacement values.

:smiley:
:smile:
:)
:-)
(:

 

[Jeremy P]

To clarify, when you start typing in a 'short-code' for a smilie or an emoji in the editor a pop-up box appears with similar suggestions. When the similar suggestions are shown the local defined smilies should be defined first over emoji that have same defined short-codes.

This is usually already the case. There are actually four priority tiers for the suggestions: smilies, emoji short-names, emoji alternative short-names, and emoji keywords. However, the short-names are checked in the order they are defined. In your case, when typing :smile, it matches against :smile: first, which leaves :smiley: open for other suggestions. It might be worth us making changes here, but you can work around this in the meantime by making :smiley: appear before :smile: in your smilie definition.

 

[Kevin]

This is usually already the case. There are actually four priority tiers for the suggestions: smileys, emoji short-names, emoji alternative short-names, and emoji keywords. However, the short-names are checked in the order they are defined. In your case, when typing :smile, it matches against :smile: first, which leaves :smiley: open for other suggestions. It might be worth us making changes here, but you can work around this in the meantime by making :smiley: appear before :smile: in your smiley definition.

I tried that, see post #2 above. Putting :smiley: at the top of the list makes it work but then breaks :smile:.

 

[Jeremy P]

Yeah, whichever matches first will leave the rest of the short-names available for different suggestions. The alternative would be to suppress any suggestions with a short-name from an earlier match, even when it's different from the matched short-name. I don't know if that's always desirable behavior either, so I'm not entirely sure if we'll be making changes here or not.

 

[Kevin]

so I'm not entirely sure if we'll be making changes here or not.

I'd be happy with the idea of having the pop-up insert the short-codes instead of the unicode; even if the pop-up preview is displaying the wrong image the final outcome would be correct. It works that way already when BB Code is toggled off in the editor, I'd be happy if I could make it do it all the time.

 

[Jeremy P]

It's not really displaying the wrong image though, it's displaying a different suggestion with a different matching short-name. It just happens to be a short-name it has in common with an earlier suggestion. I would personally consider a message resulting in a different image than the one I chose even more unexpected behavior, and it makes for a worse WYSIWYG experience to boot.

If anything I'm a bit surprised that the plain text editor doesn't just insert the unicode character when an emoji is selected from the menu.

 

[Kevin]

 

[Jeremy P]

Not definitively saying that suppressing emoji matches for all smilie short-names is a bad idea. I'm just not entirely sure, and it is a bit of an edge case. We'll have a think about it.