:') emoji string no longer recognized
See original GitHub issueSteps to reproduce
- Type
:')into composer
What happened?
What did you expect?
For the emoji picker to appear, and let me select āšā - this worked in previous versions.
What happened?
No emoji picker appears at all, string appears to not be recognized.
Operating system
Nixos 20.09
Application version
Element version: 1.8.2 Olm version: 3.2.3
How did you install the app?
NixOS repository
Homeserver
pixie.town
Have you submitted a rageshake?
No
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:7 (3 by maintainers)
Top Results From Across the Web
Java doesn't recognize my unicode emoji (error: unknown emoji)
I have a problem with Strings and Unicode in Java. I'm currently working on a bot for Discord and have to pass it...
Read more >Emoji Preset Quick Load Not Recognized Ā· Issue #2906 - GitHub
Worked in 13.3 but in 14.0 QL labels with Emojis return from presets.json as unrecognized characters. Sent value via sockets: {"ib":true,"Ā ...
Read more >Full Emoji List, v15.0 - Unicode
ā Code Browser CLDR Short Name
1 U+1F600 š grinning face
2 U+1F603 š grinning face with big eyes
3 U+1F604 š grinning face with smiling...
Read more >Sorry, millennials. The š emoji isn't cool anymore - CNN
Bad news for people who frequently use the š emoji: It is no longer cool. ... Others will string together a bunch of...
Read more >š« Beans Emoji - Emojipedia
š© Approved in September 2021 as part of Emoji 14.0. Now available across all major emoji platforms. Copy and Paste. Copy and paste...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

It would be inconsistent in a certain sense, yes, but that still seems like a better outcome to me than ācompletely brokenā⦠the root issue here is a conflict between the natural prefix of emoticons and the search prefix for emoji, both of which are
:. Thereās not going to be any answer which is fully consistent, simply because of the conflicting prefix making that impossible.So to me, the minimum reasonable solution in those circumstances would seem to be āmaximum coverage of conflict-free emoticonsā, which is a set that both
:')and:)belong to. In fact, itās not clear to me why it couldnāt support even the conflicting ones with a single character; for example, a special case of:Ofirst suggesting š® and only then listing string search results would seem reasonable to me.The original issue that you linked to (which might slightly interfere with that by unintentionally converting some emoticons to emoji) seems to have been the switch from Tab to Enter as the confirmation key for emoji selection, which in and of itself is a strange choice, considering the UI conflicts it introduces.
Even if āARIA standardsā suggest that Enter should be used, thatās not how itās commonly implemented precisely because you then canāt distinguish between two different confirmation actions (autocomplete vs. send), which also creates user confusion because it makes them uncertain whether hitting Enter will send their incomplete message or not. That does not sound good for accessibility to me.
So it seems to me that the easiest way to make the whole thing go away and make everything work for everybody again, is to just revert emoji picker confirmation to the auto-confirmation setup with Tab and Escape, instead of Enter? Or even allow Backspace to be used for cancellation as well, if you want it to match the semantics of things like MS Officeās autocorrect.
I donāt always want to send graphical emoji - especially in bridged IRC rooms, this can often be problematic because of lacking emoji support in many peopleās clients. Aside from that, the graphical emoji sometimes have a different (cultural) context from the text-based ones - this is the case for
:')for example, which in Dutch would likely be interpreted subtly differently from the graphical š (due to historical usage).For that reason, I wouldnāt want to enable automatic emoticon conversion, but would still want a way to quickly enter it as a graphical emoji when desired, as I was able to do in prior versions. Reverting to the previous logic would be fine for me - Iām not sure why it was deemed necessary to remove it in the first place, since as far as I can see it wouldnāt interfere with anything else.