Certain graphemes like "🙇‍♀" (which you might see as two separate graphemes) are comprised of three code points:

1. 🙇 U+1F647 "Person Bowing Emoji"
2. U+200D "Zero Width Joiner"
3. ♀ U+2640 "Female Sign"

So the single grapheme is the character sequence b"\xf0\x9f\x99\x87\xe2\x80\x8d\xe2\x99\x80".

Steps to Reproduce

If there is enough space in the buffer, everything is fine:

Cli { buffer_size: 10, reserve: 0, finish_with: None, truncate_with: None, debug: true, input: "🙇\u{200d}♀" }
🙇♀
+ version: 0.1.2
+ written_len: 10
+ truncated: false
+ output_bytes: [240, 159, 153, 135, 226, 128, 141, 226, 153, 128]
+ input: 🙇♀
+ input_bytes: [240, 159, 153, 135, 226, 128, 141, 226, 153, 128]

But shrinking the buffer to 9 is a bit odd:

Cli { buffer_size: 9, reserve: 0, finish_with: None, truncate_with: None, debug: true, input: "🙇\u{200d}♀" }
🙇
+ version: 0.1.2
+ written_len: 7
+ truncated: true
+ output_bytes: [240, 159, 153, 135, 226, 128, 141]
+ input: 🙇♀
+ input_bytes: [240, 159, 153, 135, 226, 128, 141, 226, 153, 128]

The output string is b"\xf0\x9f\x99\x87\xe2\x80\x8d", which includes the zero width joiner character, but it joins nothing.

Potential Fixes

It is not entirely clear what should happen here.

Option 1: Do Nothing

This might be perfectly okay. The output is still valid UTF-8 and every decoder should be able to read it. This library only guarantees UTF-8, not that the output is a sensible grapheme.

Option 2: Cut Off the Zero Width Joiner

Another option is to drop off the trailing ZWJ, leaving 🙇 b"\xf0\x9f\x99\x87\xe2". This leaves the idea of "person bowing," but drops the gender modifier.

Cli { buffer_size: 9, reserve: 0, finish_with: None, truncate_with: Some("..."), debug: true, input: "🙇\u{200d}♀" }
🙇...
+ version: 0.1.2
+ written_len: 7
+ truncated: true
+ output_bytes: [240, 159, 153, 135, 46, 46, 46]
+ input: 🙇♀
+ input_bytes: [240, 159, 153, 135, 226, 128, 141, 226, 153, 128]

This has the unfortunate side-effect of potentially changing the meaning of the written output. The family of 4 written by b"\xf0\x9f\x91\xa8\xe2\x80\x8d\xf0\x9f\x91\xa9\xe2\x80\x8d\xf0\x9f\x91\xa6\xe2\x80\x8d\xf0\x9f\x91\xa6" showing up as 👨‍👩‍👦 might change the interpretation. The cutoff of the second child is conveyed by the Err for truncation at least.

Option 3: Cut Off the Entire Trailing Emoji

If we assume the input to WriteBuf::write_str is meant to be a sequence of graphemes (which is probably a fair assumption), then the right choice is to remove the entire 🙇‍♀ as a unit.

Cli { buffer_size: 9, reserve: 0, finish_with: None, truncate_with: Some("..."), debug: true, input: "🙇\u{200d}♀" }
...
+ version: 0.1.2
+ written_len: 3
+ truncated: true
+ output_bytes: [46, 46, 46]
+ input: 🙇♀
+ input_bytes: [240, 159, 153, 135, 226, 128, 141, 226, 153, 128]

This is not an unreasonable ask if the only character of this nature is the zero width joiner. We can handle one of these funky characters, but we probably do not want to get into the business of handling arbitrary modifiers. My personal suspicion is that there are other such Unicode sequences that would fall into this category. For example: should the characters between the left-to-right mark U+200E and right-to-left mark U+200F be considered atomic? What about the opposite way?