bug#19872: 24.4; UTF8 characters of unusual width (Gnus markers)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: sva-news@mygooglest.com,  19872@debbugs.gnu.org
> Date: Thu, 19 Feb 2015 16:49:53 +1100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAIR, :align-to works in units of canonical character width, so this
> > problem does not exist.
> 
> I don't know what you mean by "canonical character width".

It's the average width of the current frame's 'default' face's font.
IOW, the value returned by 'frame-char-width'.  Display-related
functions usually count "columns" in these units.

> If we've reserved space for 20 default-width characters, and we have a
> strings like
> 
>   [12345678901234567890] Foo
>   [12345678901234567890] Foo
>   [12345678901234567890] Foo
>   [廣東話廣東話廣東話廣東話廣東話廣東話廣東] Foo
>   [12345678901234567890] Foo
>   [12345678901234567890] Foo
>   [12345678901234567890] Foo
>   [12345678901234567890] Foo
> 
> no amount of align-to will make these columns line up.

That's a separate problem.  I thought you said that you were
truncating too long strings, so I thought these cases were already
taken care of.

Do you use something like string-width or char-width to measure the
width of strings on display while accounting for wide characters like
the ones above and for zero-width combining characters?  E.g., in this
case string-width says that the string of Kanji characters is
40-column wide, even though it consists of only 20 characters.  And
for a string such as "ẛ̣", string-width returns 1, even though there
are 3 characters there: u+017f, u+0323, and u+0307, because Emacs
composes them on display into a single glyph (a.k.a. "grapheme
cluster").  Since these strings typically use different fonts, the
results are only approximately correct, but they are a much better
approximation than if you count each character as 1 column on display.