emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Entering emojis


From: Eli Zaretskii
Subject: Re: Entering emojis
Date: Sat, 30 Oct 2021 09:36:40 +0300

> Date: Sat, 30 Oct 2021 09:19:07 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, mardani29@yahoo.es
> 
> > (truncate-string-to-width "πŸ‘¨πŸ½β€β€οΈβ€πŸ’‹β€πŸ‘¨πŸΎ" 2 nil t)
> > => "πŸ‘¨"
> 
> Nothing, they should "just work", barring bugs.
> 
> What does string-width return for this string on your system?
> 
> > which is...  uhm...  In a way, this grapheme cluster thing is slightly
> > like it was during the shift to utf-8, when not all string primitives
> > worked on characters, but bytes instead.  Less dramatic, of course, but.
> > 
> > I think we'll be seeing many amusing display glitches in this area.  πŸ₯²
> 
> We shouldn't, because string-width already supports composed text.
> There's always one more bug, of course, but there are no design
> problems here, AFAICT.

And I see that there is, indeed, a bug (or a missing feature) in
truncate-string-to-width: its algorithm assumes that string-width
returns a number that is the sum of char-width values for its
constituent characters, which is not necessarily true when
character-composition is involved.  It needs instead to consider
string-width values on subsequent substrings.  It also cannot assume
that string-width is monotonically increasing in the number of
characters in the substring, as that, too, could be false when
character-composition is involved.

Again, this is nothing specific to Emoji, this can happen with any
composed text, for example any ligature that produces a single glyph
from 2 or more characters.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]