From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org, alexander.s.m@gmail.com
Subject: Re: [PATCH v2 1/1] diff.c: When appropriate, use utf8_strwidth()
Date: Mon, 29 Aug 2022 11:37:05 -0700 [thread overview]
Message-ID: <xmqqwnaqnbfy.fsf@gitster.g> (raw)
In-Reply-To: <20220829175425.cmbwtqpxrq4ppnnk@tb-raspi4> ("Torsten Bögershausen"'s message of "Mon, 29 Aug 2022 19:54:25 +0200")
Torsten Bögershausen <tboegi@web.de> writes:
> This is caused by the logic in diff.c:
> /*
> * Find the longest filename and max number of changes
> */
> for (i = 0; (i < count) && (i < data->nr); i++) {
> struct diffstat_file *file = data->files[i];
> [snip]
> len = utf8_strwidth(file->print_name);
> if (max_width < len)
> max_width = len;
> // and later
> /*
> * From here name_width is the width of the name area,
> * and graph_width is the width of the graph area.
> * max_change is used to scale graph properly.
> */
> for (i = 0; i < count; i++) {
> /*
> * "scale" the filename
> */
> // TB: Which means either shortening it with ...
> // Or padding it, if needed, and here we need
> // another
> name_len = utf8_strwidth(name);
>
>>
>> Besides, since the simple change from `strlen()` to `utf8_strwidth()` is
>> so different from changing `strbuf_addf(...)`, I would prefer to see them
>> split into two patches.
>
> Hm, that is a possiblity. Seems to ease the burden for reviewers.
Another thing I remembered (this is a comment primarily on the
original I wrote based on 'all world is ASCII' mindset that led to
the use of strlen() as a display-width indicator) in the code is
that we "abbreviate" an overly long pathname and transform renames
that originally is in the a/b/c -> a/B/c form into a/{b->B}/c form,
and IIRC they are all byte based. The latter may be OK because the
transformation is limited to '/' boundary, but the former may chomp
a single multi-byte letter in the middle, which would need to be
corrected as a part of this change.
next prev parent reply other threads:[~2022-08-29 18:37 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 [this message]
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
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=xmqqwnaqnbfy.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.