:octocat: The markdown parser used by Github supports emojis.
:interrobang: It'd be nice if they would be enabled in marked so they show up correctly in dependant projects like npm's readme pages, as they currently display as unparsed codes.
:point_right: https://github.com/isaacs/npm-www/issues/392 :point_left:
The :warning: and :x: are great for emphasis.
JavaScript has some difficulty parsing these, as it doesn't recognise the surrogate pairs unicode-encoded emoji rely on. I imagine you'd have to use buffers to get them to work, which is at odds with the way marked works internally, and wouldn't work in the browser.
But I'm happy to be proven wrong. :)
It depends: there are different types of emoji encodings:
The classic Unicode backed emoji's as used by various mobile phone operators, which indeed are not trivial to decode. I assume this is what you mean by "unicode-encoded surrogate pairs".
But the ones I meant are the colon-delimited strings you can use in Github Flavoured markdown, like :warning:: see the cheat sheet.
They are just plain vanilla text. I don't know how complex Markdown parsing is but there are a few JavaScript implementations listed on the cheat-sheet's Github page that are just RegExp-replace()-with-callback.
Oh, right โ sorry for the misunderstanding. I was indeed thinking of the unicode ones. :)
Carry on!
Glad we cleared this up :) With "Carry on!" I assume you'd like this functionality in marked?
I could have a stab at implementing it but I think it needs an architectural decision:
I think a nice way to do this is to split this up into two pieces: we add the emoji 'tag' parsing support to marked-core, but have an external 'data module/plugin'-thing with all the emoji data you'd need to register with the marked module. This would keep the bulky data away from vanilla users.
The data module would make available the list of valid emojis (could also be custom/subset), and there'd be a folder with the individual emoji images that need to be uploaded to a server/CDN (and the base url passed back to the module for linking).
Marked-core would then lex + parse the :-delimited strings and call into the data module to see if an emoji code is valid and what html to use. The data module would look this up and return the html <img> code.
With a bit of gold-plating this might even be able to switch between external images (data-traffic-friendly) or using inlined dataURLs (self-contained).
What do you think?
3 years later issue is still opened... Will marked support emojis or it won't?
Also needed a similar functionality.
I wrote simple parsser, maybe it will help someone. ๐
// parser.js
import marked from 'marked'
import emoji from 'node-emoji'
export function parse = (markdown) => {
const replacer = (match) => emoji.emojify(match)
markdown = markdown.replace(/(:.*:)/g, replacer)
return marked(markdown)
}
// use
import { parse } from './parser'
parser(':muscle: of emoji') // ๐ช of emoji
@antonreshetov You'll probably want test your function with more complex input, like multiple emoji's and regular :'s mixed together in various combinations.
@Bartvds it's just a blank, my problems are solved. If someone needs to add different combinations of regular, just describe them as needed. ๐
See #956
Closing as stale.
Right now the focus is on two Markdown specifications to pursue solid support for:
GFM and CommonMark: The GFM support appears to be an extension, not part of the core, and I haven't delved far enough into CommonMark to know if it's part of that spec. Therefore, in answer to the question of whether it will be supported...not right now. But, let's see what the future brings.
It's fine, we're using unicode emoji's these days ๐๐๐
Most helpful comment
Also needed a similar functionality.
I wrote simple parsser, maybe it will help someone. ๐