Feedback-ID: ie3de48e3:Fastmail
Date: Sat, 23 May 2026 20:50:48 -0700
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: "Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: splitting pg_resetwal output strings
Message-ID: <ahJ1UGWeVJjV79_u@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b5951fd8a69d00464e517886d6dc0b65b12bcdb6.camel@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ahJ1UGWeVJjV79_u%40alvherre.pgsql>
Precedence: bulk

On 2026-May-23, Jonathan Gonzalez V. wrote:

> Hello!
> 
> I've tested the patch, and I found that in the first patch, the nsl.mk
> file is changed to match the first argument of CONTROLDATA_LINE as the
> string to match:
[...]
> While keeping the argument as it is, I suggest to switch to
> CONTROLDATA_LINE:2 like this:

Yeah, you're correct, this is a bug in 0002.  Thanks!

> During testing, I found a couple of things that may be interesting, or
> at least worth keeping in mind for the future implementation already
> mentioned [1].
> 
> Even if the spacing calculation is correct, I found that the font size
> is not the same for different languages, so if a strings or part of it,
> is translated into, for example, Hindi, and most of it it's in English,
> it will affect how it look in the terminal, meaning that it's probably
> that a the second column will be moved to the left generating a
> misalignment in the printed data

I don't think varying font width is something we should care about.  The
multibyte system has a mechanism to tell us how wide the characters are,
in units of some monospace font.  This is what the pg_wcswidth calls are
there for (or internal_wcslength in the patch).  If the terminal doesn't
align the characters correctly according to the declared width because
different fonts are used, that's not our bug.

The idea behind the patch is to measure the length of all strings after
translation.  If a number of the strings are not translated, then we
still measure them in their final presentation form.  Then we align the
two columns based on the maximum length of all strings.  I don't think
this is any worse than what you get with the original code; if a
translator has chosen a different alignment than what English has, and
some strings are not translated, then the output will appear misaligned.
In fact, with the code it will be better (assuming no font issues),
because we will try to align correctly even the strings that aren't
translated.  In fact, if fonts differ, there's nothing the translator
can do, because there's no way to know what's the user going to do at
runtime -- users are going to have different terminals and different
fonts.

> [2] https://sw.kovidgoyal.net/kitty/

Hmm, I'm not sure what you wanted to show with this URL -- can you
elaborate?

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/