GNU bug report logs - #27505
LC_CTYPE affects tutorial language

Previous Next

Full log

View this message in rfc822 format

From: Leonard Lausen <leonard <at> lausen.nl>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 27505 <at> debbugs.gnu.org
Subject: bug#27505: acknowledged by developer (Re: bug#27505: LC_CTYPE affects tutorial language)
Date: Sat, 5 Aug 2017 17:18:23 +0900

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.