From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org, alexander.s.m@gmail.com, Johannes.Schindelin@gmx.de
Subject: Re: [PATCH v5 1/1] diff.c: When appropriate, use utf8_strwidth()
Date: Mon, 10 Oct 2022 14:58:26 -0700 [thread overview]
Message-ID: <xmqq35bv1gu5.fsf@gitster.g> (raw)
In-Reply-To: <20220926184308.5oaaoopod36igq6i@tb-raspi4> ("Torsten =?utf-8?Q?B=C3=B6gershausen=22's?= message of "Mon, 26 Sep 2022 20:43:08 +0200")
Torsten Bögershausen <tboegi@web.de> writes:
> On Wed, Sep 14, 2022 at 09:40:04AM -0700, Junio C Hamano wrote:
>
> []
>
>> I think I spotted two remaining "bugs" that are left unfixed with
>> this patch..
>> ...
> How should we proceed here ?
> This patch fixes one, and only one, reported bug,
But then two more were reported in the message you are responding
to, and they stem from the same underlying logic bug where byte
count and display columns are mixed interchangeably.
> "git log --graph" was mentioned.
> Do we have test cases, that test this ?
> How easy are they converted into unicode instead of ASCII ?
The graph stuff pushes your "start of line" to the right, making the
available screen real estate narrower. I do not think in the
current code we need to worry about unicode vs ascii (IIRC, we stick
to ASCII graphics while drawing lines), but we do need to take into
account the fact that ANSI COLOR escape sequences have non-zero byte
count while occupying zero display columns.
The other bug about the code that finds which / to use to abbreviate
a long pathname on diffstat lines does involve byte vs column that
comes from unicode. From the bug description in the message you are
responding to, if we have a directory name whose display columns and
byte count are significantly different, the end result by chopping
with the current code would end up wider than it should be, which
sounds like a recipe to cook up a test case to me.
next prev parent reply other threads:[~2022-10-10 21:58 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-09 13:11 [BUG] Unicode filenames handling in `git log --stat` Alexander Meshcheryakov
2022-08-09 18:20 ` Calvin Wan
2022-08-09 19:03 ` Alexander Meshcheryakov
2022-08-09 21:36 ` Calvin Wan
2022-08-10 5:55 ` Junio C Hamano
2022-08-10 8:40 ` Torsten Bögershausen
2022-08-10 8:56 ` Alexander Meshcheryakov
2022-08-10 9:51 ` Torsten Bögershausen
2022-08-10 11:41 ` Torsten Bögershausen
2022-08-10 15:53 ` Junio C Hamano
2022-08-10 17:35 ` Torsten Bögershausen
2022-08-14 13:35 ` [PATCH/RFC 1/1] diff.c: When appropriate, use utf8_strwidth() tboegi
2022-08-14 23:12 ` Junio C Hamano
2022-08-15 6:34 ` Torsten Bögershausen
2022-08-18 21:00 ` Junio C Hamano
2022-08-27 8:50 ` [PATCH v2 " tboegi
2022-08-27 8:54 ` Torsten Bögershausen
2022-08-27 9:50 ` Eric Sunshine
2022-08-29 12:04 ` Johannes Schindelin
2022-08-29 17:54 ` Torsten Bögershausen
2022-08-29 18:37 ` Junio C Hamano
2022-09-02 9:47 ` Johannes Schindelin
2022-09-02 4:21 ` [PATCH v3 1/2] diff.c: When appropriate, use utf8_strwidth(), part1 tboegi
2022-09-02 9:39 ` Johannes Schindelin
2022-09-02 4:21 ` [PATCH v3 2/2] diff.c: More changes and tests around utf8_strwidth() tboegi
2022-09-02 10:12 ` Johannes Schindelin
2022-09-03 5:39 ` [PATCH v4 1/2] diff.c: When appropriate, use utf8_strwidth(), part1 tboegi
2022-09-05 20:46 ` Junio C Hamano
2022-09-07 4:30 ` Torsten Bögershausen
2022-09-07 18:31 ` Junio C Hamano
2022-09-03 5:39 ` [PATCH v4 2/2] diff.c: More changes and tests around utf8_strwidth() tboegi
2022-09-05 10:13 ` Johannes Schindelin
2022-09-14 15:13 ` [PATCH v5 1/1] diff.c: When appropriate, use utf8_strwidth() tboegi
2022-09-14 16:40 ` Junio C Hamano
2022-09-26 18:43 ` Torsten Bögershausen
2022-10-10 21:58 ` Junio C Hamano [this message]
2022-10-20 15:46 ` Torsten Bögershausen
2022-10-20 17:43 ` Junio C Hamano
2022-10-21 15:19 ` Torsten Bögershausen
2022-10-21 21:59 ` Junio C Hamano
2022-10-23 20:02 ` Torsten Bögershausen
2022-09-15 2:57 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq35bv1gu5.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=alexander.s.m@gmail.com \
--cc=git@vger.kernel.org \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).