bug#60750: 29.0.60; encode-coding-char fails for utf-8-auto coding system

[Eli Zaretskii <eliz@gnu.org>]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 60750@debbugs.gnu.org
> Date: Thu, 12 Jan 2023 14:44:29 +0100
> 
> One minor nit, the description for ':endian' says:
> 
>     `:endian'
> 
>     VALUE must be `big' or `little' specifying big-endian and
>     little-endian respectively.  The default value is `big'.
> 
>     This attribute is meaningful only when `:coding-type' is `utf-16'.
> 
> That last sentence seems untrue, as ':endian' is meaningful for
> 'utf-8-auto'

That depends on what you mean by "meaningful".  What it wants to say
is that it's meaningless to change the value of this property for any
coding-system other than UTF-16.

>     Eli> Who does set utf-8-auto? where did you originally bump into this?
>     Eli> This is an obscure coding-system, and the fix to make it work as
>     Eli> documented will produce an incompatible change in behavior.  So before
>     Eli> I decide whether to make the change and on what branch, I'd like to
>     Eli> know how in the world did you encounter this.
> 
> Itʼs entirely my own fault:
> 
> The file where I noticed this is shared between a GNU/Linux and a
> macOS machine, which means I foolishly added the following a year ago,
> even though itʼs unnecessary (perhaps I was thinking I was going to be
> sharing it with a Windows machine?):
> 
>     ;; -*- lexical-binding: t; coding: utf-8-auto; -*-

So you thought the "-auto" part was about the EOL format?

> I think that means we can leave the code as it is.

??? "As it is" means this coding-system behaves contrary to
documentation: it should produce BOM on encoding.  Leaving it as is
doesn't sound TRT, so I'd like to have this fixed.  From your
description, it sounds like you bumped into this by mistake, and I see
only one other use of it -- in the test suite.  So I'm inclined to
installing this on the emacs-29 release branch.