In Unicode, "monospaced" characters are meant to take up 0, 1, or 2 character cells based on what kind of character they are. Combining characters take up 0 cells because they stack on top of the previous character. CJK characters (except for the ones designated as "halfwidth") take up 2 cells, because that's how the original CJK terminal displays were designed.

In alacritty, all characters take up 1 cell, even the ones that aren't supposed to, leading to display problems. This leads to incorrect scrolling and wrapping in tmux, for example.

To demonstrate the problem, I defined this string using python3:

text = 'u\N{COMBINING DIAERESIS}' * 200

Without Python, you could just try pasting in this string, I believe (but don't use the pre-combined character ü):

üüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüü

My terminal is 240 characters wide, so when I print(text), the result should fit on one line for me. Instead, not only does it wrap, but the unexpected wrapping causes tmux to glitch, so the entire window gets filled with columns of un-combined u and ¨ characters.

The Japanese word ありがとう should take up 10 character cells. Instead, it takes up 5 character cells, with the characters overlapping each other.

This is not a font issue, it's an issue with the actual behavior of the terminal. The lack of fallback fonts just makes the issue harder to see.

C code uses the wcwidth(3) function to determine how wide a character is. This function seems to have at one point been in the Rust standard library, then moved out. http://unicode-rs.github.io/unicode-width/unicode_width/index.html is a crate that seems to provide it.