How to disable emoji pop-up in issue editor? #11343
Description
- Gitea version (or commit ref): 1.11.4
- Git version: 2.17.1
- Operating system: Ubuntu 18.04
- Database (use
[x]):- PostgreSQLMySQLMSSQLSQLite
- Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)NoNot 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.)
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
techknowlogick commentedon May 8, 2020
REACTIONSare for reacting to tickets, not for emoji within the ticket. For example, I "reacted" to your ticket with the rocket emoji.dpifke commentedon 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.
[-]Setting REACTIONS to empty string in config doesn't disable them[/-][+]How to disable emoji pop-up in issue editor?[/+]silverwind commentedon May 8, 2020
I guess no one would oppose a PR that adds a
ui.ENABLE_EMOJI_DROPDOWN, defaulting totrue.mrsdizzie commentedon 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.
silverwind commentedon 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 viawindow.config.septatrix commentedon 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.
stale commentedon 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.
wyattoday commentedon 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.
silverwind commentedon 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 commentedon Apr 21, 2022
Edit: Actually I think the tribute.js
requireLeadingSpacewe 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.
wyattoday commentedon 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...
the reactions dialog wouldn't show. However if I typed:
then typed elsewhere in the issue, and went back and added a colon after it, the dialog would be triggered.
Similarly, if we typed...
And then backspaced over the period to change it to a colon, again the reactions dialog would be shown.
So, if there is a
requireLeadingSpaceand 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.
septatrix commentedon Apr 21, 2022
I adding a debounce before showing the popup (i.e. wait until no input was triggered for e.g. 200ms) would solve most problems because if someone is entering some flowtext there will normally not be such a delay between key presses. This would also work if someone wants to input a classical smiley :D
silverwind commentedon Apr 21, 2022
Thanks, I can reproduce the buggy popups with a key sequence like
a,:, backspace,:. In fact, just clicking into the input area again and entering a:anywhere also triggers buggy popups.requireLeadingSpaceis from https://github.com/zurb/tribute which we use, but I guess we should look for alternative modules that aren't so buggy.Delaying the popup by like 500ms is also something we should definitely do.
silverwind commentedon Apr 21, 2022
Buggy popups do not reproduce when switching the editor to textarea, so unfortunately, I think the bug may be cause by the interactions between CodeMirror and Tribute and a proper fix can only come with elimination of CodeMirror, e.g. #10729.
JulienPalard commentedon Nov 25, 2023
I'd also like to see a way to disable this. In French the "requireLeadingSpace" thing does not helps, all our colons are preceded by whitespaces.
Hopefully french people are often writing issues in english. But I happen to work on the french translation of the cpython doc, so I write in french in pull requests comments, and the popup is really annoying me.