Element-web: Automatically replace plain text Emoji doesn't work with Enter

[t3chguy]

:P[ENTER] leads to :P being sent

[MightyCreak]

Two things that would make the experience better IMHO:

• The emojis are replaced on the fly (e.g. I type ":P" and as soon as I type "P" the text is replaced by 😛)
• Be able to undo the auto-replacement (e.g. I hit ":P" but for another reason than having the emoji, because I enabled the option, it gets replaced, but if I simply hit Ctrl-Z, it returns to text)

[MightyCreak]

Another possible behaviour is that the text is converted to emojis at send time. It would look like Slack's behaviour (although it's done at receive time there).

It gives a bit less control of the user, but if the regexp are well done, I don't think that's a problem. A very deterministic regexp is to only accept begin or end of lines, or spaces before and after the text-emoji. This way, if you type :smile::) it won't give anything, but if you type :smile: :) (with a space in the middle), there you'll have two smileys.

Also, being able to edit your message is going to be a huge help for the UX. You write something, didn't expect it to be converted that way, you edit your message, now it works

[t3chguy]

/me would not like that last suggestion

[kethinov]

Hangouts also does it the way that last suggestion outlines and I agree it leads to some annoying behaviors where emojis are not intended. I like the two behaviors outlined in your first post, @MightyCreak.

[MightyCreak]

Yep, I think both suggestions have it's pros and cons, I think it would be a good idea to have something close to Slack, since most of the users that would be interested in Riot would probably already know Slack (the other users will be coming from IRC where they despise emojis, so.. they're not really the target for this feature 😆 )

[lampholder]

I think we can noncontroversially make :PEnter "do the right thing" and replace :P with a :stuck_out_tongue: if the user has that option enabled.

The other suggestions are interesting, but require more thought and are more likely to upset as many users as they please if implemented without sufficient consideration :)

[dkasak]

@lampholder What about @MightyCreak's suggestion? It sounds as if it shouldn't upset anyone since, if the user has enabled the option to replace text smileys, it's probably what he wants to happen. It also gives a way to preview what's happening before you send and a way to cancel the conversion.

[lampholder]

I think maybe what we're missing are some fundamental laws about how the composer must work.

The composer is arguably the most important part of the app, or perhaps the most personal, and small irritations will be magnified through regular use.

To my mind, it's important that the composer is:

• unobtrusive (i.e. doesn't make you type or click any more than the absolute bare minimum)
• trustworthy (i.e. always represents what you type into the timeline with 100% predictability)

I find this issue tricky because all of the options proposed risk threatening either the unobtrusiveness (ctrl-z to undo the auto-substitution in the composer that you didn't want) or the trustworthiness (usually autoreplacing :P with :stuck_out_tongue: in the composer, but special-casing :PEnter because there's no beat in the composer usage to replace the plain text with the emoji).

[MightyCreak]

Heads up: Slack changed their composer lately and now the emojis are displayed as you write (like in Riot). So if you write :P<Space>, it'll display 😛. And <Space>:P Enter replaces the smiley as well, which honestly, is what 99% of the users __that enabled emojis__ would expect (who would not expect to have a smiley when he'd write <Space>;) at the end of the sentence?).

(@lampholder what's the markdown syntax to write keyboard caps like you did?)

[lampholder]

Cool; I think we're in agreement - just to check I'll spell out my understanding:

iff the user has the _Automatically replace plani text Emoji_ option enabled

• replace :PSpace with 😛 in the composer; when the message is sent submit to the timeline as 😛
• submit :PEnter to the timeline as 😛 (without having replaced it in the composer at all

The above is true for all messages which are composed entirely of or end with a plaintext Emoji.

And @MightyCreak the keyboard styling is achieved using <kbd>P</kbd> 😁

[dkasak]

Regarding the second case, maybe require a Space before the smiley to perform the conversion? So the second example would have to be Space:PEnter, so things like (:foo:)<enter> don't get converted into (:foo:slightly_smiling_face:.

[MightyCreak]

I agree with @dkasak, I even think it should be a rule for the whole text actually. Convert to emojis only if there's a space before, or it's the beginning of a line.

[lampholder]

Yes - a plaintext emoji should never be converted when it's a substring of a larger string - only when it represents a complete and distinct word.

This does raise the question of what to do about plaintext emoticons immediately followed by punctionation (e.g. :P!). Slack's latest iteration substitutes in the composer but _after_ you've pressed space (so :P! shows :P! in the composer, but :P!Space shows "😛!").

I think here it's a toss up between:

• what Slack are doing (substitute on space), and
• initating the substitution on pressing the punctuation key

Whilst I think I personally would prefer the latter, for the sake of familiarity in consistency I'd recommend we take the same approach as Slack (there's nothing wrong with it).

[MightyCreak]

The main difference is that, in Slack, the emoji pass is always done (while sending or receiving, I don't know). The composer substitution is only aesthetic. You can write :P! or 😛!, the result will always be 😛!.

[dali99]

Another option is to autoconvert :P a few milliseconds after the P is pressed and no other keys were written (other than space) and then reverting the change if the user presses backspace.

This is similar to how many mobile keyboards auto-correct and auto punctuation can be reverted by hitting backspace as well.

[MightyCreak]

I like your proposition @dali99!

Maybe the rule could be to call the substitution algorithm each time a key is pressed, or after 500ms (to improve performances, the algorithm could be called on the current word only.)

From there, the problem would not be to know if the substitution should be done after Space, or !, or whatever key. It would just be a smart, deterministic text substitution.

[dali99]

I'm not sure I understand what you mean.
If I understand it correctly though
if one were to write :People for example it would be very annoying to press backspace after the P.

PS: How do you get those 3D keyboard keys with markdown?

[MightyCreak]

Maybe Backspace and Delete would be the only keys that would not trigger the substitution.

Thinking about it, the 500ms condition is also a problem. Say a user types very slowly an is writing :People, he would press :... P... e and that would result in 😛e. Not what he wanted.

Ok, so it seems that the condition would be:

• if a character is inserted or Enter is pressed, take the current word before the cursor and make the substitution. The substitution can't happen if it's at the end of the word.

Following this rule (and if I'm not mistaken):

• :PSpace, or :P!, or :P,, or any other valid pattern (e.g. a smiley followed by a non-word character, \W in perl regex) will be substituted in the composer
• :PEnter will be substituted before being sent
• :P won't be substituted in the composer
• :Pe won't be substituted in the composer
• :PeBackspace won't be substituted in the composer
• :PDeletee won't be substituted in the composer

PS: I asked @lampholder yesterday 😄 it's <kbd>Space</kbd>

[dali99]

I made a website to see how different ruleset "feel" so I'll try to implement the different rulesets talked about in here in the coming days.

https://dandellion.xyz/Projects/riot/composer/

It only does :'), :P and :D though, cause I didnt see a good list of what text is converted to what emoji.

And also doesn't deal with the emojipicker thing. Which needs a bit of work as well. like @lukebarnard1 said in #4554 with :L showing :Laughing: in the picker before :confused:

[neverfox]

This might be off-topic (and I'm happy to move it, if another issue exists for this), but I guess I was also expecting Riot to render known "full" emoji from the picker without having to actually select it from the picker. That is, if I type :smile:<enter> it would send the smile emoji rather than having to do :smile:<down><enter>. I have it set to automatically render plain text emoji but that doesn't appear to apply to full emoji markdown (as the name probably implies).

[pkoziol]

@dali99 your webstie seems to be down 😞

[ssbarnea]

I am not sure if this counts as the same bug or it should need a new bug but MacOS has the "text replacement" service embedded in it which I succesfully used for years, where I have lots of keyboard shortcuts that do expand as text what would take a lot of time to type.

For some weird reason, Riot MacOS client is one of the very few applications where these text replacement does not work at all. The only other one that I know that has the same problem is Chrome and there is a long standing bug for addresing this issue but fixing MacOS specific bugs (or missing features) is not really among Google devs priorities.

Instead of trying to implement this feature in Riot, i would advise on making it work with already existing OS features. I bet similar services exist for all/most supported systems.

[t3chguy]

@ssbarnea the Desktop App is an Electron application and so is based on Chromium and probably is impacted by the same bug as Chrome