Support emoji IMEs

[Tyriar]

Currently inputting emojis doesn't work on all platforms (via mac: cmd+ctrl+space, windows: win+.).

Context: vercel/hyper#1275 (comment)
VS Code: microsoft/vscode#35266

Related: #467

[parisk]

👍 I'll give this a try, because I love adding emojis in my squash messages.

[rauchg]

@parisk the technique we use in Hyper (might be useful for you) is to place the contenteditable inside the actual caret, so that its position remains relevant.

[Tyriar]

Yes we do something similar with our textarea. @parisk let me know if you need help understanding the CompositionHelper, there are two issues with it AFAIK: #273 microsoft/vscode#11334

[rauchg]

One way this issue could be fixed is by no longer hiding the textarea offscreen and instead keeping it in sync with the cursor

In our case I believe we always have it inside the caret div, so no reposition is needed. @matheuss can confirm

[Tyriar]

Our caret is an actual character on screen which may also contain text and it's reconstructed whenever the prompt line is refreshed.

[matheuss]

Yeah @rauchg, we always have our own contenteditable inside the hterm's carret (which is a floating div that happens to be above the terminal).

[parisk]

I think that we the best option for us is moving the hidden textarea to the caret's position on every stroke (similar to CodeMirror's mechanism for the hidden textarea).

What we have to investigate though is why the character is not being inserted in the terminal when click. I guess it's a focus issue, but I will get on top of it within the weekend to tell for sure.

[Tyriar]

The reason we're not getting the emoji is because we don't listen to the input event. So I guess we need to listen to that to get the changes. We may want to consider reevaluating keypress/keydown if we're also listening to input.

[parisk]

You mean ditching keypress/keydown completely for input or using it supplementary to the typical keyboard events?

[Tyriar]

Not sure yet, maybe we don't need keydown anymore? I've also been told that the input eventis needed to respect repeating chars when holding down a key on macOS.

[epicfaace]

The only way I see to do this is to handle the input event and grab the data attribute of the event object, which then gives you the emoji, such as "😄".

However, Firefox doesn't support the data attribute, so I guess we're stuck on that front.

On the other hand, only in Firefox (Mac OS X) I am able to input emojis normally, but only half of the emoji shows up:

Not sure how this is happening. Any thoughts?

[Tyriar]

@juancampa has it working on Hyper's fork, should be an incoming PR soon.

[minonl]

@Tyriar I believe they are 2 issues:

1. emoji IME input in not handled properly, which Emoji fix #1890 should fix it
2. emoji width is not calculated properly as @epicfaace mentioned, which seems to be unicode related

[minonl]

#1951

[ShlomiRex]

The only way I see to do this is to handle the input event and grab the data attribute of the event object, which then gives you the emoji, such as "😄".

However, Firefox doesn't support the data attribute, so I guess we're stuck on that front.

On the other hand, only in Firefox (Mac OS X) I am able to input emojis normally, but only half of the emoji shows up:

Not sure how this is happening. Any thoughts?

What project is this? (gif u sent)
Can I view the code please? <3

[LabhanshAgrawal]

@Tyriar this got broken in #3535
Tested on the demo, chrome 97, macOS 11.6.2

[Tyriar]

@LabhanshAgrawal could you create a new issue with a gif/screenshot of the new problem?

[LabhanshAgrawal]

@LabhanshAgrawal could you create a new issue with a gif/screenshot of the new problem?

done #3629