From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 10 Jun 2013 20:55:48 GMT
Subject: Re: [PATCH v3 1/2] rm: better error message on failure for multiple files
Message-ID: <7v4nd5fzxn.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqtxl5dfrf.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>>> +{
>>> +	if (files_list->nr) {
>>> +		struct strbuf err_msg = STRBUF_INIT;
>>> +		int i;
>>> +		strbuf_addstr(&err_msg, main_msg);
>>> +		for (i = 0; i < files_list->nr; i++)
>>> +			strbuf_addf(&err_msg,
>>> +				    "\n    %s",
>>
>> Is there an implication of having always 4 spaces here to l10n/i18n
>> here?  I am wondering if it should be _("\n    %s").
>
> I'd say this is just formatting and should be the same in every
> languages, but I'm far from an expert in the domain.

After looking at the patch again I do not think 4-SP matters.  I was
primarily worried if this was to align with some column of the first
line of output, e.g.

	error: lorem ipsum dolor sit amet, consectetur adipisicing
               elit, sed do eiusmod tempor incididunt ut labore et
               dolore magna aliqua.

but that is not what this 4-SP indent is about, so it is OK.

>>         test_expect_success 'rm files with different staged content' '
>>                 cat >expect <<\-EOF &&
>
> (that should be -\EOF, not \-EOF I think)

Sorry, my bad.  You are of course right.

>>  (2) by using a dash '-' before the end-of-here-text marker, you can
>>      align the body of here text with a leading tab (HT).
>
> This works because the list of files is aligned with spaces, but is
> seems a bit fragile to me to use this -EOF on a text which uses
> indentation. Anyway, I'm fine with both.

True.