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 14:49:35 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I wasn't talking about error messages, I was talking about other uses
> > of LANG and locale information in Emacs.  E.g., we define the default
> > coding-systems based on the locale, and detect-coding-* guesswork uses
> > it.  How does the solution you installed affect all that when, for
> > example, Emacs needs to visit a file or show an email or use
> > sub-process output encoded in Latin-1 with no charset information
> > available from other sources?
> 
> Android subprocesses won't output information in Latin-1, as the C
> library doesn't support these locales.  Furthermore, there are no OS
> locales that don't use UTF-8 under Android.
> 
> See here:
> 
>   
> https://android.googlesource.com/platform/bionic/+/master/libc/bionic/locale.cpp#51

So a program on Android cannot output an arbitrary byte stream, which
just happens to be text encoded in non-UTF-8 encoding?

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?

> > As for other programs' behavior: since when we consider that a
> > dictate?  We take the platform-specific behavior into consideration,
> > but make our decisions based on additional aspects as well.  And I
> > still don't see why in this case we should use such a simplistic
> > solution.  Is there any problem in having a mapping of the kind I
> > suggested?  If that is possible, it sounds to me like a simple-enough
> > solution that will make the Android build behave like Emacs users
> > expect, with minimal costs and with predictable success.
> 
> It is not possible, since en_US.utf8 and C are the only locales
> supported under Android.  System languages besides that are implemented
> in the GUI toolkit, which does not take LANG into consideration.

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.

I presented several specific examples where we use the locale
information for setting up defaults in Emacs, which are unrelated to
libc functions.  I don't see your responses to those examples.  So let
me ask specific questions about the behavior of the current code on
master:

  . what will be the default coding-systems in Emacs? will they always
    be UTF-8?
  . what will be the default dictionary for spell-checking? will it
    always be English?
  . 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-\' ?

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.