Re: Bug in Unicode character width in Emacs 25.1, bisected to a761fbf (Unicode 9.0.0beta import)

[Ævar Arnfjörð Bjarmason]

On Mon, Sep 19, 2016 at 6:34 PM, Eli Zaretskii <address@hidden> wrote:
>> From: Ævar Arnfjörð Bjarmason <address@hidden>
>> Date: Sun, 18 Sep 2016 20:52:44 +0200
>> Cc: address@hidden, Eli Zaretskii <address@hidden>
>>
>> [I'm sending this to the ML instead of bug-* because I figure a bug
>> caused by the Unicode 9 import will garner some wider interest than
>> your typical regression]
>
> IMO, that was a mistake.  Bugs should be reported to the bug tracker,
> and all those who might be interested are reading the bug mailing list
> anyway.  Reporting a bug with "M-x report-emacs-bug" has the advantage
> of including in the report important details about your system
> configuration that might be relevant to the issue.
>
>> The mu4e mode has a mu4e-use-fancy-chars option which if set will use
>> e.g. ⚓ (Unicode ANCHOR; U+2693) instead of "a" in the vertically
>> aligned headers view to show that an E-Mail has an attachment.
>>
>> In Emacs 25.1 this vertical alignment is off consistent with ⚓ being
>> considered a zero-width character, i.e. the content to the right-hand
>> side of the ⚓ character is shifted 1 character to the left.
>
> This character's width is 2, not zero:

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
buffer".

In any fixed-width font I try this:

    b|1
    æ|2
    ✔|3
    ⚓|4

Always shows un unbroken vertical line. I.e. the characters all have
the same display width of one. Does that display differently for you?
I.e. is the vertical bar for the line with the ⚓ on the column as the
digits for the rest?

If not, ⚓ reporting a width of 2 seems like an isolated test case for
the bug (and who knows what other characters also changed...).

Before your patch:

    (char-width ?⚓) --> 2

But now it's:

    (char-width ?⚓) --> 1

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.

Also, applying this monkeypatch works around the issue:

    diff --git a/src/character.c b/src/character.c
    index 9f60aa7..583357c 100644
    --- a/src/character.c
    +++ b/src/character.c
    @@ -314,6 +314,7 @@ usage: (char-width CHAR)  */)
       CHECK_CHARACTER (ch);
       c = XINT (ch);
       width = char_width (c, buffer_display_table ());
    +  width = 1;
       return make_number (width);
     }

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.

>> I'm sorry that I don't have a more isolated test case than "run mu4e,
>> turn on mu4e-use-fancy-chars and check out the misalignment in the
>> header view" but I figure with the bisect + my successfully testing a
>> revert of a761fbf on top of emacs-25.1 we have enough info to get
>> started in narrowing this down.
>
> Unfortunately, this description is not enough.  And since it is
> unlikely we'll decide to revert that commit, we need more information
> to understand what code (or font?) is the culprit and how to fix that.
>
> For starters, I don't yet have a clear idea of what display problems
> are caused by that character; a screenshot would help.  The results of
> "C-u C-x =" with point on the anchor character would also be of value.

I attached a minimal screenshot. The topmost line is correctly
aligned, but the subsequent two are out of alignment with it.

I get the exact same output with C-u C-x = before & after a761fbf, so
it's surely the same output you're seeing:

> Finally, does selecting a different font for this character fix the
> problem?

emacs-bug-a761fbf.png
Description: PNG image