Re: [PATCH v11 06/10] convert: add 'working-tree-encoding' attribute

From: Torsten Bögershausen <tboegi@web.de>
Date: Apr 5, 2018, 16:41 UTC
Message-ID: <583f9ec3-3aef-d823-9fd6-3cc126ac47f6@web.de>
In-Reply-To: <0FEBEFB2-46D6-4688-AF07-654B56FFF9D8@gmail.com>

On 01.04.18 15:24, Lars Schneider wrote:

Show 14 quoted lines

>> TRUE or false are values, but just wrong ones.
>> If this test is removed, the user will see "failed to encode "TRUE" to "UTF-8",
>> which should give enough information to fix it.
> 
> I see your point. However, I would like to stop the processing right
> there for these invalid values. How about 
> 
>   error(_("true/false are no valid working-tree-encodings"));
> 
> I think that is the most straight forward/helpful error message
> for the enduser (I consider the term "boolean" but dismissed it
> as potentially confusing to folks not familiar with the term).
> 
> OK with you?

Yes.

Another thing that came up recently, independent of your series:

What should happen if a user specifies "UTF-8" and the file has an UTF-8 encoded BOM ? I ask because I stumbled over such a file coming from a Windows which the java compiler under Linux didn't accept.

And because some tools love to put an UTF-8 encoded BOM into text files.

The clearest thing would be to extend the BOM check in 5/9 to cover UTF-32, UTF-16 and UTF-8.

Are there any plans to do so?

And thanks for the work.