>For example, iTerm2 considers the "rosette" emoji to have width 1 It's not the case here, but for some emoji there's another issue: Unicode 9 changed the wid

>For example, iTerm2 considers the "rosette" emoji to have width 1 It's not the case here, but for some emoji there's another issue: Unicode 9 changed the width for some codepoints (mostly emoji) from 1 to 2, and iTerm until very recently (don't know if it's released yet) defaulted to the Unicode 8 widths, with an opt-in escape sequence to change to Unicode 9. >This approach comes from the wcwidth utility, and the comment at the top of the C source file provides further insight into the difficulties faced here. That's link goes to Markus Kuhn's implementation from 2007. It supports Unicode 5, and is by now woefully out of date. You don't want to use it anymore. Most terminals have their own definition, and the annoying part is that the client application and the terminal need to have theirs in sync or they get weird glitches when moving the cursor. Shameless plug: Fish's solution is widecharwidth[0], which is a python script that parses the Unicode data files and generates a wcwidth for C++, Javascript and Rust. It's still a wcwidth, meaning that it has issues with joining code points, but it's at least a start. It's up-to-date with Unicode 14 and, unless they change the data format (again) should be easy to update to future Unicode releases. It's public domain and used by at least fish and WezTerm. [0]: https://github.com/ridiculousfish/widecharwidth https://github.com/ridiculousfish/widecharwidth