On Thu, May 21, 2026 at 12:42 PM Branko Čibej <[email protected]> wrote:
> On 21. 5. 26 18:25, Timofei Zhakov wrote: > > On Wed, May 20, 2026 at 3:20 PM Branko Čibej <[email protected]> wrote: > >> On Wed, 20 May 2026, 14:40 Daniel Sahlberg, <[email protected]> >> wrote: >> >>> Den ons 20 maj 2026 kl 10:55 skrev <[email protected]>: >>> > >>> > Author: rinrab >>> > Date: Wed May 20 08:55:33 2026 >>> > New Revision: 1934426 >>> > >>> > Log: >>> > Use UTF-8 alignement for the 'author' column in the 'svn blame' >>> command. >>> > >>> > * subversion/svn/blame-cmd.c >>> > (#include): Add svn_utf_private.h. >>> > (print_line_info): Call svn_utf__cstring_utf8_align_right() to >>> > prepare author. >>> > >>> > Modified:Agreed, this is a very breaking/broken >>> > subversion/trunk/subversion/svn/blame-cmd.c >>> > >>> > Modified: subversion/trunk/subversion/svn/blame-cmd.c >>> > >>> ============================================================================== >>> > --- subversion/trunk/subversion/svn/blame-cmd.c Wed May 20 08:30:24 >>> 2026 (r1934425) >>> > +++ subversion/trunk/subversion/svn/blame-cmd.c Wed May 20 08:55:33 >>> 2026 (r1934426) >>> > @@ -24,6 +24,7 @@ >>> > >>> > /*** Includes. ***/ >>> > >>> > +#include "private/svn_utf_private.h" >>> > #include "svn_client.h" >>> > #include "svn_error.h" >>> > #include "svn_dirent_uri.h" >>> > @@ -150,8 +151,9 @@ print_line_info(svn_stream_t *out, >>> > time_stdout = " >>> -"; >>> > } >>> > >>> > - SVN_ERR(svn_stream_printf(out, pool, "%s %10s %s ", rev_str, >>> > - author ? author : " -", >>> > + SVN_ERR(svn_stream_printf(out, pool, "%s %s %s ", rev_str, >>> > + svn_utf__cstring_utf8_align_right( >>> > + author ? author : "-", 10, pool), >>> > time_stdout)); >>> >>> After this change the output of svn blame is different from before if >>> there is a very long author name. >>> >>> I have tested with svn compiled about a month ago (the version in >>> $PATH) and from a brand new (in ./subversion/svn). I have prepared a >>> repo with a file where all lines are authored by "dsg" and the >>> remaining by "averylongauthor" (15 characters, ASCII). >>> >>> This is my commit #2 by the long author: >>> [[[ >>> dsg@devi-25-01:~/svn_trunk3$ ./subversion/svn/svn proplist -v >>> --revprop -r2 ../wc/foo >>> Unversioned properties on revision 2: >>> svn:author >>> averylongauthor >>> svn:date >>> 2026-05-20T11:52:35.534418Z >>> svn:log >>> Modify line 4 >>> ]]] >>> >>> Blame before the change above: >>> [[[ >>> dsg@devi-25-01:~/svn_trunk3$ svn blame ../wc/foo >>> 1 dsg 1 >>> 1 dsg 2 >>> 1 dsg 3 >>> 2 averylonga Line 4 >>> 1 dsg 5 >>> 1 dsg 6 >>> 1 dsg 7 >>> 1 dsg 8 >>> 1 dsg 9 >>> ]]] >>> Author names are right adjusted but when overflowing, the first 10 >>> characters are displayed. >>> >>> Blame after the change above: >>> [[[ >>> dsg@devi-25-01:~/svn_trunk3$ ./subversion/svn/svn blame ../wc/foo >>> 1 dsg 1 >>> 1 dsg 2 >>> 1 dsg 3 >>> 2 longauthor Line 4 >>> 1 dsg 5 >>> 1 dsg 6 >>> 1 dsg 7 >>> 1 dsg 8 >>> 1 dsg 9 >>> ]]] >>> Author names are right adjusted but when overflowing, the last 10 >>> characters are displayed. >>> >>> (I'm aware there are more instances of svn_stream_printf and I haven't >>> analysed exactly which one is involved here). >>> >>> I think we need to keep the precision in the formatting string and use >>> the _align_left version. >>> >>> Kind regards, >>> Daniel >>> >> >> >> Agreed, this is a very breaking/broken change. Changes that affect >> program output need to be discussed on list and tested. This comment caught >> my attention: >> >> >> + * Please note, there might be a little artifact when there is a wider >> + * character, then the string won't be perfectly aligned. >> >> >> If true, it implies that svn_utf8_width() or whatever the function is >> called isn't returning correct results. >> >> I can't find the discussion about this now but I'd just note that >> calculating the width of a Unicode string by only looking at individual >> code points is not correct. Therefore, pruning away individual code points >> without context in order to get a shorter string is not correct, either. >> Some Unicode glyphs can use up to 5 code points. >> >> -- Brane >> >> Whoever sold us Unicode as a fixed-width encoding was running a pyramid >> scheme. 😏 >> > > I did NOT mean to intentionally break anything. Please don't say that a > change is fundamentally broken just because you don't like something. > > The implementation might've been bad - it's not the idea. > > > Changes that affect program output need to be discussed on list and > tested. > > I completely disagree. First of all, we live by commit-then-review. Of > course we need to discuss important design decisions that we make. This is > not one of these. > > Second, I did not want to change behaviour. This was a mistake that I > made. I did not realise that if you resize a box of UI anywhere else, the > text still stays on the left side, ok? Please don't insult me for not > knowing how to think or whatever that was that you meant. > > > > You need to calm down. And test your changes more thoroughly. > > > We already had incidents of certain people spoiling features because of > the "wrong discussion and approval" process. I want to avoid them as much > as possible in the future. This really creates a toxic environment on > dev@svn. I encourage that we stay respectful to each other and keep > conversations constructive. > > Yes, review is important. But not to the point where we have the least > significant things go through patches. Sometimes you can just do a thing. > > By the way, did it ever stop you from breaking the trunk for over 6 months > and delaying the release for some extra time and refusing to revert changes > after you were pointed out that it was actually breaking? I didn't see you > reverting that. > > > Show me where I broke trunk for 6 months and which release I delayed. > Please do. Then tell me again about the toxic environment. > > > -- Brane > > Folks, please let's not get upset. I would rather assume a careless choice of words than anything nefarious. Also I made a careless choice myself when I said the old code is "wrong." It's not wrong, but there are edge cases it doesn't handle. By that definition, any code to fit an author name into a fixed width column will be "wrong" because of all the possibilities and minutiae that exist in Unicode and all the languages of the world. So, to answer my own question of what is "right" here, there doesn't seem to be any simple straightforward "right," only endless room for future improvement. So, I shouldn't have said the old code was wrong. Careless choice of words on my part. I apologize. I think everyone says things that could have been said better. Let's not read too much into each other's specific word choices or we'll all be in a bad mood all the time. Cheers, Nathan
