From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Leonard Lausen Newsgroups: gmane.emacs.bugs Subject: bug#27505: acknowledged by developer (Re: bug#27505: LC_CTYPE affects tutorial language) Date: Sat, 5 Aug 2017 17:18:23 +0900 Message-ID: <7d9c1e09-eec9-763f-8180-1d592d806702@lausen.nl> References: <871soq7pyr.fsf@users.sourceforge.net> <44eb186d-db67-3e93-31cd-8260f5df7781@lausen.nl> <83k22iwl13.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1501921159 3963 195.159.176.226 (5 Aug 2017 08:19:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 5 Aug 2017 08:19:19 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 Cc: 27505@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 05 10:19:11 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dduIc-0000Ks-MV for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Aug 2017 10:19:06 +0200 Original-Received: from localhost ([::1]:55783 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dduIi-00082r-T8 for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Aug 2017 04:19:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dduIb-00082g-Ts for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 04:19:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dduIY-0005VG-3u for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 04:19:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39761) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dduIX-0005V7-Vy for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 04:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dduIX-000427-Qk for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 04:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Leonard Lausen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Aug 2017 08:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27505 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27505-submit@debbugs.gnu.org id=B27505.150192111515470 (code B ref 27505); Sat, 05 Aug 2017 08:19:01 +0000 Original-Received: (at 27505) by debbugs.gnu.org; 5 Aug 2017 08:18:35 +0000 Original-Received: from localhost ([127.0.0.1]:42438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dduI7-00041R-2N for submit@debbugs.gnu.org; Sat, 05 Aug 2017 04:18:35 -0400 Original-Received: from hercules.uberspace.de ([95.143.172.224]:48044 ident=8qmFMcgevpD) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dduI4-00041G-Qo for 27505@debbugs.gnu.org; Sat, 05 Aug 2017 04:18:33 -0400 Original-Received: (qmail 12834 invoked from network); 5 Aug 2017 08:18:30 -0000 Original-Received: from localhost (HELO ?192.168.0.14?) (127.0.0.1) by hercules.uberspace.de with SMTP; 5 Aug 2017 08:18:30 -0000 In-Reply-To: <83k22iwl13.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:135393 Archived-At: Hey Eli, thanks for your reply. > Yes, there should be such a way, and in fact it is already, and > always was, implemented in Emacs. The values of LC_CTYPE etc. > environment variables are only used to set up the _defaults_; users > can use commands and options to override those defaults in many ways. > For example, "C-h t" can be invoked with a numeric argument ("C-u C-h > t") in which case Emacs will ask you in what language to display the > tutorial. As another example, input method of your choosing can be > invoked at any moment with "C-u C-\"; then you can switch it back > off as soon as you've finished typing characters that are not > directly accessible from your system keyboard. Finally, the > language environment of your choosing can be set with "C-x RET l", > and doing that will set many other defaults according to the > language environment you select. I was not aware of the feature to change the tutorial language via "C-u C-h t". Thanks for pointing that out. > Given all these facilities, I'm not sure I understand what exactly > is your problem. The original report was about the tutorial > language, but you never explained why did you set LC_CTYPE to the > value that specified Chinese. If you did that for some reason other > than for using Chinese in your programs, then perhaps you shouldn't > set LC_CTYPE, and instead should use the above-mentioned, more > focused, Emacs features to specify Chinese where you want it? Sorry for not being clear about it. To input Chinese, Japanese or Korean (CJK) on Linux people usually rely on tools such as fcitx or ibus, which allow inputting CJK characters in any application. They are also supported by emacs via the X Input Method (XIM) protocol. Unfortunately XIM is only supported in emacs when LC_CTYPE is set to a CJK locale (#10867: must export LC_CTYPE to zh_CN.UTF-8 or similar CJK locale to use X input method). Compared to using emacs input methods, fcitx provides the same experience for all desktop applications and arguably better statistical matching methods to match the user input (Latin characters) to the target CJK Characters, so it is preferable over the emacs input methods ("C-u C-\"). I would be more than happy to not set LC_CTYPE to Chinese, if #10867 gets fixed. Until then it seems the only way to get XIM working. If I remember correctly though, #10867 is intended behavior and won't be fixed (which is not sensible IMO). My problem is, that just because I would like to use XIM doesn't mean that I would like to see any of the emacs interface in the LC_CTYPE language. So given that #10867 seems to be intended behavior at least emacs shouldn't rely on LC_CTYPE to change the interface language in any user-visible way. From my perspective it would make more sense to fix #10867 though. > That'd go against the Posix semantics of these variables, so we > shouldn't do that, because it might not be what is expected by users > who set both LANG and other LC_* variables. > > As I wrote previously, I don't really understand the exact problem > we are asked to solve here. I don't think we should be discussing > solutions before we understand the actual problem. Right now, I > believe that Emacs already provides features to resolve any such > problems. As far as I understand the current behavior of emacs to change the interface language based on LC_CTYPE is application defined behavior that is not part of Posix. At least according to http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html : > This variable determines the locale category for character handling > functions, such as tolower(), toupper() and isalpha(). This > environment variable determines the interpretation of sequences of > bytes of text data as characters (for example, single- as opposed to > multi-byte characters), the classification of characters (for > example, alpha, digit, graph) and the behaviour of character classes. > Additional semantics of this variable, if any, are > implementation-dependent. So I see no problem with LANG defining the interface language and LC_CTYPE taking care of the character handling.. Best regards Leonard PS: Besides emacs bug 10867 there is also an Ubuntu bug from 2009 https://bugs.launchpad.net/ubuntu/+source/emacs-snapshot/+bug/434730 Or in Chinese forums https://emacs-china.org/t/emacs-gui/1271