bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27505: acknowledged by developer (Re: bug#27505: LC_CTYPE affects tu


From: Leonard Lausen
Subject: bug#27505: acknowledged by developer (Re: bug#27505: LC_CTYPE affects tutorial language)
Date: Sat, 5 Aug 2017 18:52:38 +0900
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

> I don't see any experts we have who could fix that, unfortunately.

> But I don't see why that would be a problem for you: if you don't want
> that Emacs language environment be Chinese when you use XIM, you
> should be able to invoke set-language-environment inside Emacs after
> starting it, to set the language environment to something other than
> Chinese.  Does that work for you?

That is a good workaround. I created this bug report, as I would expect
this as default behavior though.

Unfortunately XIM currently does not work for me at all. So I can't
confirm that changing set-language-environment won't stop XIM from
working. (Though XIM  worked for me before making a switch from
Debian-based to Gentoo.. Bug
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27312 ).

>> 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. Posix only says:
>>
>>> 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.
> 
> See the "interpretation of sequences of bytes of text data as
> characters" parts: that's what causes Emacs to use LC_CTYPE to setup
> the language environment.  So we do follow Posix, AFAIU

Hm, as long as LANG and LC_CTYPE both are UTF-8 locales, the
interpretation of bytes would be the same. In principle the interface
language is independent from the interpretation of bytes right? One
could just parse the first part of LANG (i.e. "en_EN") do decide the
display language but follow LC_CTYPE for the interpretation of bytes.
This seems also to be what the majority of applications are doing, given
that I set LC_CTYPE to Chinese system wide, but only emacs (and Dropbox)
are changing their interface language (more specifically the tutorial
language).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]