How to disable emoji pop-up in issue editor?

[dpifke]

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

[techknowlogick]

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

[dpifke]

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.

[silverwind]

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

[mrsdizzie]

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]

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.

[septatrix]

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]

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]

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]

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]

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.

[wyattoday]

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

[septatrix]

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]

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.

requireLeadingSpace is 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]

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]

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.