How to disable emoji pop-up in issue editor? #5367

Originally created by @dpifke on GitHub (May 8, 2020).

Gitea version (or commit ref): 1.11.4
Git version: 2.17.1
Operating system: Ubuntu 18.04
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant

Description

99.99999% of the time when I type a colon (:), I want to insert a colon. I don't ever want emoji in my issue descriptions, and the pop-up is super-annoying.

I tried to disable the pop-up by setting REACTIONS to an empty string in the [ui] section of app.ini. But this didn't work.

If disabling these via REACTIONS is not practical, an additional configuration option is needed. (I'm OK with reactions being available via a dedicated UI button but not every time I type colon.)

Originally created by @dpifke on GitHub (May 8, 2020).   - Gitea version (or commit ref): 1.11.4 - Git version: 2.17.1 - Operating system: Ubuntu 18.04 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant ## Description 99.99999% of the time when I type a colon (:), I want to insert a colon. I don't ever want emoji in my issue descriptions, and the pop-up is super-annoying. I tried to disable the pop-up by setting `REACTIONS` to an empty string in the `[ui]` section of `app.ini`. But this didn't work. If disabling these via `REACTIONS` is not practical, an additional configuration option is needed. (I'm OK with reactions being available **via a dedicated UI button** but not every time I type colon.)

GiteaMirror added the topic/ui issue/confirmed outdated/theme/markdown labels 2025-11-02 06:22:44 -06:00

GiteaMirror commented

@techknowlogick commented on GitHub (May 8, 2020):

REACTIONS are for reacting to tickets, not for emoji within the ticket. For example, I "reacted" to your ticket with the rocket emoji.

@techknowlogick commented on GitHub (May 8, 2020): `REACTIONS` are for reacting to tickets, not for emoji within the ticket. For example, I "reacted" to your ticket with the rocket emoji.

GiteaMirror commented

@dpifke commented on GitHub (May 8, 2020):

Ah, perhaps I'm confused because the first two emoji which pop up when I type colon are +1 and -1, and the behavior started when I upgraded Gitea from a version which didn't have reactions. My issue is with the text-entry pop-up, not the concept of reacting to issues.

@dpifke commented on GitHub (May 8, 2020): Ah, perhaps I'm confused because the first two emoji which pop up when I type colon are +1 and -1, and the behavior started when I upgraded Gitea from a version which didn't have reactions. My issue is with the text-entry pop-up, not the concept of reacting to issues.

GiteaMirror commented

@silverwind commented on GitHub (May 8, 2020):

I guess no one would oppose a PR that adds a ui.ENABLE_EMOJI_DROPDOWN, defaulting to true.

@silverwind commented on GitHub (May 8, 2020): I guess no one would oppose a PR that adds a `ui.ENABLE_EMOJI_DROPDOWN`, defaulting to `true`.

GiteaMirror commented

@mrsdizzie commented on GitHub (May 8, 2020):

Maybe a config option that lets you decide what tribute items to enable/disable. Right now I think we just have usernames and emojis, but I could see issues being a future addition as Github has. with all of them defaulting to on.

@mrsdizzie commented on GitHub (May 8, 2020): Maybe a config option that lets you decide what tribute items to enable/disable. Right now I think we just have usernames and emojis, but I could see issues being a future addition as Github has. with all of them defaulting to on.

GiteaMirror commented

@silverwind commented on GitHub (May 8, 2020):

Right, maybe a ui.DISABLE_MARKDOWN_EDITOR_DROPDOWNS = emoji,username (default empty). It's a runtime setting so it needs to be handed down to JS via window.config.

@silverwind commented on GitHub (May 8, 2020): Right, maybe a `ui.DISABLE_MARKDOWN_EDITOR_DROPDOWNS = emoji,username` (default empty). It's a runtime setting so it needs to be handed down to JS via `window.config`.

GiteaMirror commented

@septatrix commented on GitHub (May 14, 2020):

I think a delayed popup like it Github seems to use is preferable. The popup does not steal keyboard input or similar but sometimes can be annoying when typing fast.

@septatrix commented on GitHub (May 14, 2020): I think a delayed popup like it Github seems to use is preferable. The popup does not steal keyboard input or similar but sometimes can be annoying when typing fast.

GiteaMirror commented

@stale[bot] commented on GitHub (Jul 13, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Jul 13, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

@wyattoday commented on GitHub (Apr 21, 2022):

We also run into this. We frequently type colons, and get random emoticons throughout issues if we're not watching the screen while we type.

Not great UI. So, this is a real bug that needs fixing.

@wyattoday commented on GitHub (Apr 21, 2022): We also run into this. We frequently type colons, and get random emoticons throughout issues if we're not watching the screen while we type. Not great UI. So, this is a real bug that needs fixing.

GiteaMirror commented

@silverwind commented on GitHub (Apr 21, 2022):

I think we should just make the : popup trigger smarter: It should only trigger the popup when the preceding character is either whitespace, newline or if there is no content yet. That alone should eliminate a lot of false triggers on the dialog.

The code for this is in tribute.js. If anyone wants to contribute, I think this would be a good first issue.

@silverwind commented on GitHub (Apr 21, 2022): I think we should just make the `:` popup trigger smarter: It should only trigger the popup when the preceding character is either whitespace, newline or if there is no content yet. That alone should eliminate a lot of false triggers on the dialog. The code for this is in [tribute.js](https://github.com/go-gitea/gitea/blob/main/web_src/js/features/tribute.js). If anyone wants to contribute, I think this would be a good first issue.

GiteaMirror commented

@silverwind commented on GitHub (Apr 21, 2022):

Edit: Actually I think the tribute.js requireLeadingSpace we already set does covers many accidential emoticons already. More control on the popup may require replaceing tribute.js which is non-trivial.

@wyattoday can you maybe describe a few entered text sequences where accidential emoticon popup occurs? I too get them sometimes, but I can't seem to recall the exact sequences to trigger it.

@silverwind commented on GitHub (Apr 21, 2022): Edit: Actually I think the tribute.js `requireLeadingSpace` we already set does covers many accidential emoticons already. More control on the popup may require replaceing tribute.js which is non-trivial. @wyattoday can you maybe describe a few entered text sequences where accidential emoticon popup occurs? I too get them sometimes, but I can't seem to recall the exact sequences to trigger it.

GiteaMirror commented

@wyattoday commented on GitHub (Apr 21, 2022):

@silverwind

Typically it's going back and adding a colon to a line before a list. Whether that's changing a period to a colon or adding a colon where there was no punctuation.

Does that make sense?

So, if I were to type...

TODO:

the reactions dialog wouldn't show. However if I typed:

TODO

then typed elsewhere in the issue, and went back and added a colon after it, the dialog would be triggered.

Similarly, if we typed...

X should be changed to Y.

And then backspaced over the period to change it to a colon, again the reactions dialog would be shown.

So, if there is a requireLeadingSpace and you're using it, then its implementation is buggy.

Github handles this correctly. In fact, I've never accidentally triggered their "reactions" popup (I had never actually seen it until deliberately trying to trigger it right now).

Edit: I've searched the other JS in the repository and don't see any other references to requireLeadingSpace. So, it looks like a property that was never implemented in whatever code is used to decide when to render the popup or not.

I don't have the time right now to dig into which JS file exactly does that rendering, so can't make a quick fix here.

@wyattoday commented on GitHub (Apr 21, 2022): @silverwind Typically it's going back and adding a colon to a line before a list. Whether that's changing a period to a colon or adding a colon where there was no punctuation. Does that make sense? So, if I were to type... > **TODO**: the reactions dialog wouldn't show. However if I typed: > **TODO** then typed elsewhere in the issue, and went back and added a colon after it, the dialog would be triggered. Similarly, if we typed... > X should be changed to Y. And then backspaced over the period to change it to a colon, again the reactions dialog would be shown. So, if there is a `requireLeadingSpace` and you're using it, then its implementation is buggy. Github handles this correctly. In fact, I've never accidentally triggered their "reactions" popup (I had never actually seen it until deliberately trying to trigger it right now). **Edit:** I've searched the other JS in the repository and don't see any other references to `requireLeadingSpace`. So, it looks like a property that was never implemented in whatever code is used to decide when to render the popup or not. I don't have the time right now to dig into which JS file exactly does that rendering, so can't make a quick fix here.

GiteaMirror commented