Hyper doesn't correctly handle variable-width characters, namely, emojis from the "noto-emoji" font. This issue is also prevalent in libvte and some Qt based terminal emulators. It works in the st emulator which apparently uses a different wcwidth implementation.
Here's a comparison between my same Tmux session looking broken in Hyper and appearing as it should in st:

You can also see that the spacing on the tmux pane title is messed up, strangely resizing the window sometimes fixes this unpredictably.
Thanks for the report. I believe @tibotiber is currently looking into this, and his PR is very close!
@wyqydsyq would you mind trying the code on #1536 to confirm if it fixes your issue?
We've got a bit of a mixup: #1536 talks about more about powerline, but comments mention emoji as well. This issue is titled as to cover quite wide base, including plain emoji, but then talks specifically about emulators and issues shown are not regarding the characters but the UI of the emulator.
So, since emoji is "variable-width", it also falls into this issue, I mean things like:

I would help to test @tibotiber question above but I have no clue how to get the emulators in question set up. @wyqydsyq please follow up to Thibaut's question.
Windows 10 version 1709, Hyper 1.4.8
Display problem with emoji's: 馃巻馃巻馃巻馃巻馃巻

Notice the cursor when repeating the last command with ARROW KEY UP.
Sorry for the late reply, I stopped using Hyper due to this issue. I just tried the latest stable version which apparently has #1536 merged, however still get undesirable results. Screenshot attached shows a comparison with the display from Tilix which is how it should look.

similar problem occurred on v3.0.2
I actually used hyper as an example in an article I wrote about varying Unicode Version level support in Terminals (and a solution that works for python), https://jeffquast.com/post/terminal_wcwidth_solution/
The gist of it is that Hyper supports only version 5.1.0 of the Unicode standard for wide characters, through its depenency on the wcwidth library, whereas version 9.0 introduces the specification of Emoji's, from the article above,
Chinese, Japanese, and Korean users, whose languages use full-width characters almost exclusively have been the most impacted by this problem, whereas the Western world only seemed to notice it with the introduction of emoticons in Unicode version 9.0.
The problem is the depenency on the wcwidth library, that library does not support any newer version. I haven't yet found a javascript version that has been brought up-to-date (Latest Unicode specification is version 13.0)
best wishes !!
@wyqydsyq @jquast can you check again with the latest ci build
I ran the ucs-detect tool with the new changes and it showed UNICODE_VERSION=12.1.0; export UNICODE_VERSION

Everything looks great now, thanks
Everything looks great now, thanks
What is this tool you're using?
pip install wcwidth blessed
then, this is the script: https://github.com/jquast/wcwidth/blob/master/bin/wcwidth-browser.py