Re: [BUG] ZLE character width with emoji presentation variation selectors in Unicode

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On Fri, May 10, 2024 at 7:12 PM Advait Maybhate <advait@xxxxxxxx> wrote:
>
> Gotcha, thanks for the context! Combining emojis are weird :)
>
> Hmm, agreed that it won't be possible to use the same standard across all terminals - hence, I was thinking terminfo would allow the terminal to indicate whether it supports these variation selectors with wide characters?
>
> Yep, I was referencing TR51 from Unicode as well (emoji presentation selectors).

From what I could tell (I'm not an expert), there is no phrasing that
implies the width should be different for the emoji presentation form
and the text presentation form.

> From looking a bit into wcwidth, it seems like it doesn't inherently support width for a sequence of code points. I just tried this out in C++ with ICU (International Components for Unicode library) and grapheme clusters to demonstrate the width calculation as 2 with this sequence: gist.github.com/Advait-M/a326cd2e474b9520dc893765ec4cb2c4.

Yes, normal compose sequences are a base character with a width, and
composing characters with 0 width (but effectively rendering to the
left of the insertion point, on top of the base character.)

-- 
Mikael Magnusson