:') emoji string no longer recognized

[joepie91]

Steps to reproduce

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

[SimonBrandner]

We removed emoticon autocomplete and made the autocomplete window show up only after you type more than 2 characters. If you type :') and have the emoticon conversion enabled it should get converted to 😂

This was intentional (see #18593), what about the current behaviour is exactly the problem, how would you like this to work?

Related #18833

[joepie91]

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.

[SimonBrandner]

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.

See #18593

I'll let design decided what they want to do here

[joepie91]

That does not seem related; :') is two characters after the : and so should not be affected by a two-character minimum.

[SimonBrandner]

Well, it would be weird, imo, if you could autocomplete :') but not :)...

[joepie91]

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 :O first 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.

[leftshift]

I totally agree with enter confirming the first autocomplete suggestion not being great.

I sometimes use the :'D emoticon (which, fair, is a bit uncommon) and if I want to end a message with it, I now instead end up replacing it with ✌️ which is not what I wanted. It also just does not make too much sense as the first suggestion to me, but that's a different issue.