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

[Gregory Heytings <gregory@heytings.org>]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]


>>> 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.
>

Agreed, yes.

>> 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.
>

I have no idea either, I was thinking aloud.  But what is clear (at least 
to me) is that this change is inevitable at some point.  UTF-8 has been 
the default encoding almost everywhere for two decades or so, and that's 
unlikely to change in the forseeable future.  In that world we cannot 
continue forever to let Emacs choose another encoding based on some 
heuristics, because "nobody" expects that anymore.  Unless there's a good 
reason to do so, of course.

>
> 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.
>

I keep all that in mind, yes 😃