-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Emoji autocomplete #3316
Comments
I'm currently working on this: Any suggestions how it should be visualized? To keep previewing the emojis performant, I limited the results to 6 elements - using substring search in the emoji list (because tributejs would start listing ALL emojis, resulting in performance issues). Datasource is taken from emojify directly, so updating emojify is sufficient to have the autocomplete up to date. Its entirely on the clientside. |
I think it would be better if picture would be first and only than name |
How about this? Requires a small change in the css, but won't break and uses the same style like #3136. |
I like the second one better. Needs maybe some tweaking, but is far better than the first one. |
Please don't make entering a single colon trigger ajax
requests and waste CPU cycles on showing icons, or let
user opt-out to that.
|
@strk I understand your concerns. GitHub starts the lookup after typing a single colon, if there is a blank before the colon. Tributejs does the same - so there is no call for typing I accomplished to make tribute start the lookup after the first character is typed after the colon - do we want that?
|
so there is no call if you are typing `bla:` - but for `bla :`.
If I type `bla :` I'm likely about to type `bla :)` so a popup
for emoji would turn my simple ASCII based smile into something
that's likely harder to read from an ASCII terminal, like
:slighly_smiling_face: or something.
Anyway, I just tried it on GitHub and have to admit that
implementation does not really disturb me as I can keep typing
w/out the popup getting in my way. If Gitea implementation is
also so fast I'm ok with it. Using the already-loaded emoji
would probably be fast.
Instead I don't like to see the actual emoji instead of the
"source" code. There is a "preview" tab, so why having the
non-ascii thing in there ? Note that if you type the code
(ie: :slightly_smiling_face:) you do get the behavior I'm
looking for (icon in preview, code in "Write" tab).
|
Closed because merged with #3433 |
I know, this is very low priority.
It would be nice if we could have autocompletion for emojis in issue comments, much like Github or Discord do: You start typing
:
and it opens up a list with emojis to choose from.This is probably related to #2456, I think the implementation would be very similar.
The text was updated successfully, but these errors were encountered: