unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Leonard Lausen <leonard@lausen.nl>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 27505@debbugs.gnu.org
Subject: bug#27505: acknowledged by developer (Re: bug#27505: LC_CTYPE affects tutorial language)
Date: Sat, 5 Aug 2017 18:52:38 +0900	[thread overview]
Message-ID: <7cdd7d3f-f704-1180-f95b-e243e4c2a658@lausen.nl> (raw)
In-Reply-To: <837eyiweyh.fsf@gnu.org>

> 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	other threads:[~2017-08-05  9:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <871soq7pyr.fsf@users.sourceforge.net>
2017-06-27 14:48 ` bug#27505: LC_CTYPE affects tutorial language Leonard Lausen
2017-06-27 15:05   ` Eli Zaretskii
2017-06-27 15:13   ` Andreas Schwab
     [not found]   ` <handler.27505.C.150189707129878.notifdonectrl.0@debbugs.gnu.org>
2017-08-05  1:54     ` bug#27505: acknowledged by developer (Re: bug#27505: LC_CTYPE affects tutorial language) Leonard Lausen
2017-08-05  2:06       ` npostavs
2017-08-05  5:59         ` Leonard Lausen
2017-08-05  7:10         ` Eli Zaretskii
2017-08-05  7:06       ` Eli Zaretskii
2017-08-05  8:17         ` Leonard Lausen
2017-08-05  9:17           ` Eli Zaretskii
2017-08-05  9:52             ` Leonard Lausen [this message]
2017-08-05 10:15               ` Eli Zaretskii
2017-08-05 10:50                 ` Leonard Lausen
2017-08-05 11:09                   ` Andreas Schwab
2017-08-05 11:20                     ` Leonard Lausen
2017-08-05 11:22                       ` Leonard Lausen
2022-04-17 19:44                 ` bug#27505: LC_CTYPE affects tutorial language Lars Ingebrigtsen
2017-08-05  8:18         ` bug#27505: acknowledged by developer (Re: bug#27505: LC_CTYPE affects tutorial language) Leonard Lausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7cdd7d3f-f704-1180-f95b-e243e4c2a658@lausen.nl \
    --to=leonard@lausen.nl \
    --cc=27505@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).