Arch Linux User Repository

I can definitely see some of the new emoji 17 glyphs 🫪. I'm using ttf-twemoji, and I can see support was added last month. Regardless, I don't think this is exactly the problem I was referring to, because it's more that the emoji source you suggested doesn't have emoji 17 at all, despite the recent commit messages suggesting that it did.

EDIT: I can see the glyph above in Vim, but it looks like tofu in Firefox. Also, I would have thought even if there are glyphs missing in the font, then Emote would still list them, but just display them as tofu.

EDIT2: It looks like there is a pending issue and pull request to add all the Emoji 17 glyphs. I don't entirely understand the original commit message then, as I assumed "Update dependency emojibase-data to 17.0.0" meant Emoji 17 support had already been added. Maybe it's just a bug and they didn't add complete support. I'm not really sure if there is a better source for the list of emoji, perhaps something more official, but I couldn't really find anything in the same format. In any case, I'll wait until mid-January to see if the pull request is accepted, then I'll push a new version to support Emoji 17.

EDIT3: Finally updated to 4.1.0-3. Looks like openmoji do a gradual rollout for the different emoji versions, so I'll just try and update it as they come. There are more authoritative sources, but Emote (upstream) uses the openmoji database, and the format is slightly distinct, so I'll just stick to using openmoji. Happy for someone to write a script to support the full latest emoji version if they like!

I think we can't see glyphs from Emoji 17 yet because our emoji font of choice doesn't support them. The spec was updated very recently, as you noticed. It will take some time for fonts to adopt. Following through on the researching this suspicion, there are indeed no recent commits for googlefonts/noto-emoji nor discord/twemoji. I would say to go ahead and push the update to this package. When font releases happen, you shouldn't have to do anything as a maintainer; the app will just start showing them in the picker.

Sorry for the delay @ardency. I've added your "hack", which works great. (There was a small typo in the install, but I worked it out.) I can confirm that I can build it with Emoji 16 is now supported! Thank you for the tip.

Having said that, before I push the new PKGBUILD, I think Emoji 17 is out, but doesn't seem to be supported? It pretty new, but the emoji source that you suggested has a commit from two weeks ago saying Update dependency emojibase-data to 17.0.0. I identified some of the new emoji from this Emoji 17, but I can't see them in the github list above, and they don't work in Emote either, obviously. Any ideas why? Is that a good source and/or is there a better one?

The emoji list is out of date. It only contains glyphs up to Emoji 14 (c.f. additions to 15 and 16.) This patch updates the static map of emoji glyphs/names/codepoints that Emote draws from. After applying it, rebuilding and restarting the program, the emoji list will be updated to contain glyphs current as of Emoji 16.

for cases like this on the GitHub repo

@ardency sorry, what are you referring to? I don't really understand what problem your post is trying to address.

There have been multiple updates to Twemoji and Openmoji since the package was updated last by the developer. They provide instructions for updating the emoji list for cases like this on the GitHub repo. Following those instructions before progam compilation adds support for many glyphs added in Emoji 16.

7c7
< pkgrel=2
---
> pkgrel=3
18c18,19
<         'setup.py' # might be better to patch upstream rather than hardcoding a completely new version
---
>       'https://raw.githubusercontent.com/hfg-gmuend/openmoji/master/data/openmoji.csv'
>       'setup.py' # might be better to patch upstream rather than hardcoding a completely new version
21a23
>             '24d2c4c29ba90a1074b0fbc2213d43fa3eedd02d145b67cf031ffc3112755776'
41c43,45
<   install -Dm 644 -t "$srcdir/$_pkgname-$pkgver/emote/static/" "$staticdir"/{emojis.csv,logo.svg,style.css}
---
>   install -Dm 644 -t "$srcdir/$_pkgname-$pkgver/emote/static/" "$staticdir"/{logo.svg,style.css}
>   # Update emoji from remote
>   install -Dm 644 "$srcdir/$_pkgname-$pkgver/emote/static/emojis.csv" "$srcdir/openmoji.csv"
66d69
<

The proper way to do this would probably be to create a new AUR -git package for otf-openmoji (hfg-hmuend/openmoji), require that package by this one during build, and copy data/openmoji.csv from it into the appropriate location of this package's build dir (static/emojis.csv) but this hack I've provided works fine for now.

Thanks @ZimbiX! No worries, I'll remove the patch for the next tagged release.

Thanks for adopting the package, @Rhinoceros! Your updates were excellent.

PR #154 (manimpango removal) has now been merged, so the patch is no longer needed here =)

Edit: Ah, well, that would be the case if there'd been a release. I forgot this isn't a '-git' package.

I've adopted and fixed up the package. I'm removed the manimpango dependency and patched various files as per a pull request upstream. I've moved the X11 dependency to optdepends, and added a patch for Wayland support. There have also been a few minor clean ups. Please let me know if I've broken anything or if there are any other issues!

In addition to all the pending issues below that have remained with no response... There is a fix available to make this work in Wayland, but upstream will not patch it for non-flatpack or snap versions. Hence, the fix should be applied here in this PKGBUILD.