Closed jgm closed 1 year ago
Another problem with emojis is that their set changes over time. So, there's (theoretical) forward compatibility hazard with :emoji_which_will_exist_in_2025:
To clarify, is this about removing just the emoji table (so, the user still can write :smile:
, it's just that it doesn't get replaced) or about remoting the :ident:
syntax from djot?
We could go either way. I guess it would make sense to keep the emoji parsing, just remove the replacement with a unicode character. Then the filter would be quite easy and efficient; it would just have to match on the emoji elements rather than doing a pattern recognition on each str.
Thinking about this a bit more, a case could be made for redesignating the emoji
element as something more general-purpose, which could be resolved to emojis but could be put to another use. E.g. special
.
We have extensible containers for blocks, inlines, verbatim block, verbatim inline. But we don't have an extensible leaf node -- this could be it.
This is a good idea but please note my comment at https://github.com/jgm/djot/issues/44#issuecomment-1215075532 that {:some text:}
should probably also be supported, and that a decimal or hexadecimal number should be allowed between the colons as probably being the best way of representing arbitrary characters by codepoint.
https://github.com/kitsunies/emoji.lua seems to be a nice emoji library. We could remove our djot.emoji module and instead either
1) handle emojis using a filter that uses this rock, or 2) make emoji support optional in the HTML renderer and depend on this rock if it is selected
The tests would no longer contain resolved emojis. Either way, we could compile the support into the web playground (amalg.lua will include the module if it's installed and you ask it to).
Let me copy my thoughts about emoji notation from #175 here.
I don't think emoji notation is necessary because
:dog:
directly in the text. Input methods support inputting emojis these days.:walking_man:
on GitHub and :man-walking:
on Slack. It's not easy to remember which one is correct for users so parsers need to support the both patterns. But supporting both patterns makes the emoji symbols list bigger and messy.:
character will be free and a parser will get simpler.@rhysd's excellent points boils down to: Today, π
for all intents and purposes is plain text just like a
, b
and c
.
Currently djot includes a giant table of emoji aliases so it can do substitutions for
:smile:
. While this is undoubtedly useful for some purposes, I wonder if it would be better implemented as an optional filter. It should be relatively easy to create an emoji filter -- performance would have to be tested.