Problem with emoji sizes

[Offirmo]

Boxen is amazing but has troubles with emojis.

I tried to devise a PR myself, but apparently it's in a sub-sub dependency, so you'll be faster than me at fixing it:

I enclosed the strings with " to ensure it was not from my side.
Here is the text for reproducing:

🙂  CHARACTERISTICS 💗
"👶🏽  level.........1"
"💗  health........1"
"💙  mana..........0"
"🏋🏽  strength......1"
"🤸🏽  agility.......1"
"🏊🏽  vitality......1"
"👵🏽  wisdom........1"
"🤹🏼‍♀️  luck..........1"

[Offirmo]

I used the latest iTerm on macOs. The standard terminal app has the same problem:

[Offirmo]

I really need this for a pet project. I'm starting working on it. Will send PRs.

[kevva]

Sounds like it's related to sindresorhus/string-width#2.

[Offirmo]

Figured it out. I'm working on is-fullwidth-code-point and string-width but that's SUPER HARD !!!

[Offirmo]

This is insanely hard, but PRs coming soon.

[Offirmo]

See also: https://gitlab.com/gnachman/iterm2/issues/5293

[Offirmo]

Progress so far:

[LinusU]

I think that the behaviour might have changed between macOS Sierra and High Sierra. I saw the same thing in one of my projects here: LinusU/emoji-commit#6

[Offirmo]

@LinusU thanks for sharing. Unicode 9 introduced full/half width emojis, that feature may have landed in High Sierra.

[Offirmo]

Sindre didn't answer to my PRs and I lost interest. Sorry guys. Maybe at a later time.

[screendriver]

@sindresorhus any updates regarding emoji support in boxen?

[sindresorhus]

This is how it looks in the latest boxen and iTerm2. Almost:

[Caesarovich]

Sadly I think this issue should be closed without resolving. It appears that the issue is entirely related to how each terminal handles emojis (May also be an issue with the fonts used), and how to display them as characters. For example here is how it looks on

• Windows Powershell:
  
• Windows CMD:
  
• Ubuntu (SSH -> MobaXTerm)
  

So from the boxen point of view, the library outputs a string with exactly the number of characters needed per line and all. But the issue just depends on what the terminal makes those character appear on the screen. I regret to say that but that's nothing that can be done on boxen's side. I think the issue was brought here because boxen makes the problem more apparent, but is not causing it.

What do you say @sindresorhus ?

Sorry for the wait (2017 lol) and the deception.

[Offirmo]

Yes, it's depending on the level of unicode support from the underlying platform.

While I believe there are ways to improve boxen and string-width behavior, this will never work perfectly. I agree that the return-on-investment is not worth it.