[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in Unicode character width in Emacs 25.1, bisected to a761fbf (U
Re: Bug in Unicode character width in Emacs 25.1, bisected to a761fbf (Unicode 9.0.0beta import)
Mon, 19 Sep 2016 23:17:11 +0300
> From: Ævar Arnfjörð Bjarmason <address@hidden>
> Date: Mon, 19 Sep 2016 21:12:00 +0200
> Cc: address@hidden, address@hidden
> Sorry, I had it the other way around, I should have said 2, not zero, anyway:
> > (char-width ?⚓) => 2
> That seems like the bug in question. According to the docs of
> char-width it returns "width of CHAR when displayed in the current
> In any fixed-width font I try this:
> Always shows un unbroken vertical line. I.e. the characters all have
> the same display width of one. Does that display differently for you?
Yes, I see a different display: the last 2 lines have their vertical
lines shifted to the right, as these two characters are wider.
> I.e. is the vertical bar for the line with the ⚓ on the column as the
> digits for the rest?
This is clearly a matter of the font used for this (here, it's Symbola
for the two symbols and Courier for the letters).
> If not, ⚓ reporting a width of 2 seems like an isolated test case for
> the bug (and who knows what other characters also changed...).
It's not a bug. mu4e should either align text in pixels (e.g., using
the 'space' display property), or live with this limitation.
In general, an application that uses unusual symbols in the middle of
plain text should expect misalignment due to different fonts having
different sizes for the same characters, and because unusual symbols
might come from a font that is different from what the default face
> The display issues I'm seeing are consistent with the rendering
> machinery thinking it has a width of two, and thus subsequent columns
> fall out of alignment.
As expected: the character is wider than normal, at least with the
fonts I have here, so the misalignment is expected, because counting
in columns, like mu4e does, is inaccurate in these use cases.
> That patch is obviously not meant to be applied as a fix, but just
> shows that pretending that everything has a width of 1 again (which in
> the case of what mu4e shows, everything does) makes things align
> properly again.
Which is clearly wrong, since not all characters have the same width.
> I get the exact same output with C-u C-x = before & after a761fbf, so
> it's surely the same output you're seeing:
We cannot see the same output because we use different fonts.
> > Finally, does selecting a different font for this character fix the
> > problem?
What about this question?