From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master e4e1e268c8e 2/2: Set a default locale on Android Date: Fri, 08 Dec 2023 09:08:16 +0200 Message-ID: <83edfx189r.fsf@gnu.org> References: <83sf4d2894.fsf@gnu.org> <83il5919fo.fsf@gnu.org> <87edfxmbnk.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4610"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 08 08:08:59 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rBUyo-0000xl-Uk for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Dec 2023 08:08:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rBUxx-0005NG-L5; Fri, 08 Dec 2023 02:08:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBUxu-0005Mn-KW for emacs-devel@gnu.org; Fri, 08 Dec 2023 02:08:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rBUxu-00052G-Bb; Fri, 08 Dec 2023 02:08:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7qUSvgALHIAovPISVwjzNy6L5YvJPVsEkP2TIPNE5vw=; b=IcxLqW+q2FjO mSYlkaMg78bFfbN/TtLF5RcwmBZiSI/6QZzanu/1s3dnM5JOE0CrKvOIFg+2ifBurOuH5LgPrFqf4 W3AWgrwiJUABgG8blPAj03Kr75ggS0TO5dM/BPEIZqFZqPaCDsogDT0+/9X25pRYqyTeiAZJ4whYP haRf7FHqvvUmr8l9SOlxLGMev7CJ/990VjUoYz/Se5wJwG/qS5yq46ALguLwUi3CuM1SXrtYj5s11 pOVroPc+28gHT+y6lHaixvhMFjNt4mBk1QLZMpVzwrysu0UPq5BVKBstMcVNfvArRfXP/eJOoP0sO NJFc/pnzVI/BbCsw2WS3VA==; In-Reply-To: <87edfxmbnk.fsf@yahoo.com> (message from Po Lu on Fri, 08 Dec 2023 14:49:35 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:313605 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Fri, 08 Dec 2023 14:49:35 +0800 > > Eli Zaretskii 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.