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

[Advait Maybhate <advait@warp.dev>]

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

Agreed that there's no particular phrasing for this in the Unicode spec wrt
the exact width differences. I believe that'll largely be left up to the
renderer (in web, mobile, desktop, etc. contexts).

Given that, it seems like the optimal path forward might be to ask the
terminal emulator for this information to ensure alignment in what the
shell thinks vs. the terminal (for widths)?

Gotcha re composing characters - that makes sense, thanks for explaining!

But yep, I've got a fallback mechanism here in mind for Zsh (render as 2
cells wide but only reserve 1 cell, to match the shell, similar to iTerm) -
my goal with opening this issue was to kick off a discussion on the
"correct" way to approach this in Zsh and how to best support this going
forward. Since the current experience I've got in mind is suboptimal for
Zsh (compared to Bash/Fish) within Warp, for example, due to these
limitations.

Best,
Advait

On Fri, May 10, 2024 at 2:57 PM Mikael Magnusson <mikachu@gmail.com> wrote:

> On Fri, May 10, 2024 at 7:12 PM Advait Maybhate <advait@warp.dev> 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
>

[-- Attachment #2: Type: text/html, Size: 2908 bytes --]