Re: [RFC PATCH 2/3] usage: prefix all lines in `vreportf()`, not just the first
- From
- Martin Ågren <martin.agren@gmail.com>
- Date
- May 29, 2018, 04:49 UTC
- Message-ID
- <CAN0heSq1y3XibCFDYsae5b6jmzZOzcLHT4atCZ+KCb4dL5As0g@mail.gmail.com>
- In-Reply-To
- <xmqq8t83ihd7.fsf@gitster-ct.c.googlers.com>
On 28 May 2018 at 23:45, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
> Duy Nguyen <pclouds@gmail.com> writes: > >>>> +error: sub/added >>>> +error: sub/addedtoo >>>> +error: Please move or remove them before you switch branches. >>>> Aborting >>>> EOF >>> >>> This shows the typical effect of this series, which (I subjectively >>> think) gives us a more pleasant end-user experience. >> >> Also, very subjectively, I'm torn about this. To me, just one >> "error/warning/fatal" at the start of the first paragraph feels much >> better. If we have to somehow mark the second paragraph that "this is >> also part of the error message" then it's probably better to rephrase.
Would you feel the same about "hint: "? We already do prefix all the lines there. It seems to we we should probably do the same for "hint: " as for "warning: ", whatever we decide is right.
Show 10 quoted lines
> I personally can go either way. If you prefer less noisy route, we > could change the function signature of vreportf() to take a prefix > for the first line and another prefix for the remaining lines and > pass that through down to the "split and print with prefix" helper. > > That way, we can > > - allow callers to align 1st prefix (e.g. "error: ") with the > leading indent for the second and subsequent lines by passing the > second prefix with appropriate display width.
I suspect this second prefix would always consist of strlen(first_prefix) spaces? We should be able to construct it on the fly, without any need for manual counting and human mistakes.
Show 9 quoted lines
>
> - allow translators to grow or shrink number of lines a given
> message takes, and to decide where in the translated string to
> wrap lines.
>
> Even though step 3/3 may become a bit awkward (the second prefix
> would most likely be only whitespace, and you'd need to write
> something silly like _("\t")), we can still keep the alignment if we
> wanted to.Thanks both for your comments. I'll see what I can come up with.
Martin