Re: [PATCH v5 1/1] diff.c: When appropriate, use utf8_strwidth()

From: Torsten Bögershausen <tboegi@web.de>
Date: Oct 20, 2022, 15:46 UTC
Message-ID: <20221020154608.jndql5sio3jyii3z@tb-raspi4>
In-Reply-To: <xmqq35bv1gu5.fsf@gitster.g>

On Mon, Oct 10, 2022 at 02:58:26PM -0700, Junio C Hamano wrote:

Show 35 quoted lines

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

I couldn't find how to trigger this code path.
The `git log --graph` help says:
--graph
    Draw a text-based graphical representation of the commit history
    on the left hand side of the output.
    This may cause extra lines to be printed in between commits,
    in order for the graph history to be drawn properly.
    Cannot be combined with --no-walk.

There is no indication about filenames or diffs in the resultet output. If someone has time and knowledge to cook up a test case, that would help.

For the moment, I don't have enough spare time to spend on digging how to write this test case, that's the sad part of the story. And that is probably a good start, or, to be more strict, an absolute precondition, if I need to change another single line in diff.c

I still haven't understood why the current patch can not move forward on its own ? There is a bug report, patch, a test case that verifies the fix.

What more is needed ? To fix all other bugs/issues/limitations in diff.c ? If yes, they need to go in separate commits anyway, or do I miss something ?

Can we dampen the expectations a little bit ?