bug#57531: 28.1; Character encoding missing for "eo"

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 05 Sep 2022 12:59:21 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: jonathan@jonreeve.com, 57531@debbugs.gnu.org
> 
> >> I think expecting systems to be well-configured and to contain accurate 
> >> information about that exotic locale is a bit too optimistic.
> >
> > What would you suggest that Emacs does instead?
> 
> I don't know, because anything that it could do would be backward 
> incompatible.

The only change I could think of that is almost backward-compatible
(except for this single locale) is the one I posted, if we modify it
to also make the 'lang-info' pseudo-encoding override the locale.alias
file.

> What is clear is that, on reasonably modern systems, legacy 
> locales are not used anymore, and their use is discouraged (e.g. the 
> Debian installer does not present you with any legacy encoding, they 
> remain available but to activate them you need to edit the /etc/locale.gen 
> file manually).  So perhaps Emacs could always assume UTF-8, and use 
> another encoding only when there are good reasons to do so (e.g. when 
> opening a file with a legacy encoding).  The presence of the equivalence 
> eo / Latin-3 in locale.alias is IMO not a good enough reason.

I have no idea what this kind of change could do.  Maybe nothing,
maybe breakage across the board.  Keep in mind that the default
encoding is used for stuff other than decoding text in files Emacs
visits, and also for some important tasks during startup.

I also think our encoding detection doesn't always succeed to discern
between UTF-8 and single-byte Latin-N encodings.