-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom or more-fleshed-out emoji support? #11169
Comments
I support the idea of custom emojis. I understand there are a lot of features that deserve priority, but many teams love their custom emojis (and gifs), it would be a very welcome feature. |
This feature should be called "stickers" not to confuse them with actual unicode emoji. |
Stickers are great, but one of the things both slack & mastodon support is adding custom emoji, that behave the same way as regular emoji. Personally I feel that is distinct from stickers. Facebook supports both stickers and emoji, and Matrix.org recently got stickers in the riot/synapse ecosystem, but it's not the same as custom emoji, which is acknowledged in their proposal document. Stickers are a fine feature but they're not the same as being able to define custom emoji. My slack team makes heavy use of custom emoji, which have found their way to my mastodon instance as well. It may seem silly but I'm pretty unwilling to switch to any chat platform that doesn't have them, at this point :) Editing to add: there were emoji before unicode, which people have always custom-made with basic text, like I did at the end of the previous paragraph. Unicode emoji is just one kind of emoji. I think a good modern emoji system doesn't depend on unicode but has an abstracted design in which unicode emoji coexist with png/gif/svg and maybe jpg. |
I think stickers = you can only send them one at a time. not in the middle of sentences. emoji = literally Japanese for "picture letters" which implies being mid-sentence. Thus they can be inserted in mid-sentence. |
This is one of those technically uninteresting, but socially crucial issues. Per group emoji/sticker sets would address a big gap w/ Slack. |
Just pinging this so that the feature gap between Telegram/Slack and KB is addressed. People care more about not losing features than getting a few new ones. |
I'll add another vote to the pile for this feature |
Aye! This is important for team culture. Would love to see this happen. |
+1 to this feature. There are some conversations that are simply incomplete without the accent flare of custom emojis. |
Also crucial to be able to use custom emojis (or what you want to call them) in reactions! |
+1 would be great to have custom emojis |
+1 My friends and colleagues coming from Slack miss this feature greatly. We simply must allow the cult of the party parrot to expand to Keybase! 😄 |
+1 😘 |
It's in v5.4.0- https://github.com/keybase/client/releases |
How do you delete a custom emoji? |
It doesn't appear to exist yet, #23929 |
This seems to only apply to the CLI, keybase-gui supports the removal of emojis as of v5.4.0. To answer @klue, under Team Info > Emojis you should see a contextual menu button (three horizontal dots) next to each emoji, select that and then select 'Delete emoji". |
Thanks Chris. I was actually able to delete it via the |
I can't seem to delete any. I added a few custom emojis not paying attention to what channel I was in, and later tried deleting them with the cli - no error but they're still available in any channel. I went in a few channels to Team Info > Emojis and there are none available. |
@alien35 happy with the result? ready to close? |
Looks awesome! @xkr47 |
I realize emojis are not at the top of anyone's radar, but they're pretty essential for people moving away from Facebook.
There are a couple of options:
I currently have an image collection in my public folder. I can drag-and-drop the images from the folder onto the chatroom, but with time it'll clog the database with a large amount of duplicate data. A renderable link would just have enough data to point to the source of the file and then render whatever's in the source. Naturally security considerations would have to be taken into account for that to happen, in which case option 1 is easier/potentially-safer.
Also, I know an artist who'd be happy to make a pack.
The text was updated successfully, but these errors were encountered: