Subject: bug#20623: XML and HTML files with encoding/charset="utf-8" declaration loose BOM; Coding system is reset from utf-8-with-signature to utf-8 on save

From: Eli Zaretskii <[email-masked]>
Date: Sat, 11 Aug 2018 13:45:17 +0300

> Date: Sat, 11 Aug 2018 12:13:41 +0200
> From: Vincent Lefevre <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked], [email-masked]
> 
> On 2018-08-11 12:15:31 +0300, Eli Zaretskii wrote:
> > In this case, I cannot but express my extreme surprise to see such a
> > minor issue described as "grave".  The alleged data loss is minor, if
> > it exists at all (the BOM is not data important for the user,
> 
> You're completely wrong. The presence of BOM or not is very important
> for some applications, such as Firefox (not to determine the charset,
> but the MIME type of local files).

Please provide the details, including the use case, if possible.  I'm
still in the dark regarding the importance of the BOM in UTF-8 encoded
HTML stuff.

> It can be repaired, but the problems are the user doesn't know
> what's going on and this breaks things.

I agree about the user not knowing, but that doesn't yet qualify as
"data loss", which has an widely accepted meaning.

> If some package removed the execute permission of some utility in
> /bin, this would also be a grave bug, though it can easily been
> repaired.

Well, I disagree about the "grave" part, because that means the
package is unusable, causes data loss, or introduces a security hole
allowing access to the user account.  None of that is true in the case
in point.