Gitea: Emoji autocomplete

[kolaente]

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.

[lunny]

2456 has been resolved by https://github.com/go-gitea/gitea/pull/3136. Maybe someone could send another similar with #3136 to resolve this.

[modmew8]

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.

[lafriks]

I think it would be better if picture would be first and only than name

[modmew8]

How about this?

Requires a small change in the css, but won't break and uses the same style like #3136.

[kolaente]

I like the second one better. Needs maybe some tweaking, but is far better than the first one.

[strk]

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.

[modmew8]

@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 bla: - but for bla :.

I accomplished to make tribute start the lookup after the first character is typed after the colon - do we want that?

Another way would be to make the initial lookup return the emojilist we are using as feedback reaction emojis:
Since they are already loaded and there are no additional ajax calls.
My fault, does not.

[strk]

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).

[thehowl]

That seems to be pretty much what he did (bringing attention to the image, we can see that the previous cat shortcode is not converted into 🐱 but stays :cat:)

[modmew8]

Demonstration:

[kolaente]

Closed because merged with #3433