Re: master e4e1e268c8e 2/2: Set a default locale on Android

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 08 Dec 2023 15:24:02 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So a program on Android cannot output an arbitrary byte stream, which
> > just happens to be text encoded in non-UTF-8 encoding?
> 
> Such situations are possible under any system, as programs which don't
> observe the C library's configuration can always output text in a coding
> system at variance with it.

If that encoding is consistent with the current system locale, Emacs
is expected to be able to decode it.

> > And anyway, what about the other examples I gave, with visiting files
> > and receiving email? what about them?  How can Android prevent such
> > files or such email messages from getting into Emacs?
> 
> Emacs should detect the coding system from a coding: cookie or the
> file's content, just as it does under other systems where utf-8-unix is
> the locale-coding-system.

Again, if the current locale is not UTF-8, Emacs should be able to
decode text even in the absence of any cookies.  When the file's
contents could be decoded with more than a single coding-system, Emacs
uses the locale's defaults to break the tie.

> > We are mis-communicating.  I wasn't talking about using the locale in
> > the libc calls, I was talking about the places and the functionalities
> > where Emacs uses the locale to determine some of its defaults, which
> > are unrelated to what libc does.  For example, we don't use libc
> > functions for decoding and encoding text, we do that in our own code,
> > and that code has its defaults set according to the locale.  So even
> > if libc must think we are in en_US.utf8, the Emacs code doesn't have
> > to, and it should still tailor its behavior wrt i18n to the current
> > locale.
> 
> The coding system is quite immaterial here, as none of the Android
> system languages prescribe any other than utf-8-unix.

Once again: Emacs is expected to support more than that, it is
expected to behave according to the current system locale.

> >   . what will be the default coding-systems in Emacs? will they always
> >     be UTF-8?
> 
> Yes.
> 
> >   . what will be the default dictionary for spell-checking? will it
> >     always be English?
> 
> Yes, unless the system's spell checker is being used.
> 
> >   . what will be the default language-environment in Emacs? will it
> >     always be UTF-8? if so, what would be the default input method to
> >     be turned on when the user types 'C-\' ?
> 
> It'll always be UTF-8, and typing C-\ should prompt the user for the
> input method to enable.

Such behaviors are unacceptable.  We should fix them so that Emacs on
Android behaves like it does on other platforms, or else we cannot
release such an Android port.  Please work on fixing these glaring
omissions.

> > These are just a few examples of locale-dependent behavior that we
> > have in Emacs; there are likely others.  We need to discuss how to
> > give users of Emacs on Android the behavior they expect in these
> > functionalities, regardless of what the underlying libc supports.
> 
> These are all meaningful considerations, but they don't really pertain
> to locale-coding-system or LANG, as no circumstances under Android can
> arise that warrant setting it to a value besides utf-8-unix.

I disagree, and the above examples confirm my worries.  This must be
fixed.