Emoji’s start off as simple text-based combos like :-), :-o etc.
You have to be an old dog like myself to remember the times when we used text-based emoji’s on Unix talk.
So, there are a large number of combinations starting with a colon that may map into an emoji, but shouldn’t if it is not separated by a space (for example, the :/ above, when attached to http, should obviously mean http:// instead of an emoji). Without this space rule, the MarkDown processor has no way to tell if there should be an emoji or not.
So, my suggestion remain: automatically add a space in front (or both in front and after) the emoji, when chosen by the emoji picker.
Or, alternatively, modify the emoji processor to only recognize fully-spelt emoji names in non-space applications. For example: :/ is only recognized with a space before, but :confused: is always recognized wherever it is.
Modifying the MarkDown processor may be a bit hairy…
My suggestion of adding a space in front of an emoji chosen from the emoji picker dialog requires simply changing one single line. MarkDown is mostly not space conscious, so adding an extra space in most places will do nothing to it.
I think we can make two changes to make this a little bit easier to use:
Emoji selector should insert a leading and trailing whitespace when it inserts an emoji.
Replacing of Unicode emojis should work even when there are no surrounding whitespaces.
So, Hello🙂world should work the same as Hello 🙂 world and use the correct Emoji image from Discourse .
I like this.
This happens a lot in my discourse site. My users forget to add a white-space before inserting emoji’s. I’m guessing its because they are not used to that - because in other platforms like whatsapp etc. its somehow taken care automatically.
@gerhard
Is it going to be a quick fix at Discourse end?
Or do you think this can be accomplished using CSS too?
We can’t do the trailing one because of diversity level modifier :woman:t4: it would break the flow of selecting :woman: and then typing t to display the menu.
As far as I recognized it, this got added with the enable_inline_emoji_translations site setting. I noticed that emojiEscape and emojiUnescape didn’t support that site setting so I added it