unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: 12392@debbugs.gnu.org
Subject: bug#12392: emacs-gtk misinterprets floating-point numbers under certain locales on openSUSE 12.2
Date: Sat, 22 Sep 2012 08:19:48 +0200	[thread overview]
Message-ID: <87zk4ifukb.fsf@Rainer.invalid> (raw)
In-Reply-To: <87r4qbodec.fsf@Rainer.invalid>

Holger Arnold writes:
> 1. Emacs changes the locale _after_ GTK has been initialized, which,
> according to the GTK docs, "may produce inconsistent results and is
> not really supported" (see
> http://developer.gnome.org/gtk/stable/gtk-General.html#gtk-set-locale).

No, this docstring talks about gtk_set_locale, which emacs doesn't want
or need to change.

> 2. To make the parsing (and printing?) of number literals in Emacs
> Lisp locale-dependent is the wrong approach.

There are a lot of things that are wrong with internationalization, but
this isn't one of them IMHO.  Emacs does call setlocale for it.

> What is happening here is that, after Emacs's second call to
> fixup_locale() (after initializing GTK), a module implicitly loaded by
> GTK (GStreamer in this case, accessed by GTK via libcanberra) calls
> setlocale(LC_ALL, "") again.  The GTK docs explicitly say that such
> things may happen.

Please cite chapter and verse: if it's documented, then there should be
a documented way of dealing with it.  Otherwise a _library_ changing the
locale out from under a program is a bug, especially when it is already
guaranteed that the library comes into existence in a sane locale
environment.  I'd think that the gstreamer part is what has changed
between openSUSE 12.1 and 12.2, BTW.

> Note that inserting gtk_disable_setlocale() before gtk_init() does not
> help because this setting does not transcend to the loaded module.

That dangling carrot looks appealing, but it appears we'd really want to
gtk be initialized with the users' locale and not with the emacs altered
one.

> A quick work-around is to start Emacs with LC_NUMERIC set to "C".
>
> The long-term solution would be to fix Emacs's Lisp parser so that it
> does not depend on the current locale.  Hard-setting the locale to "C"
> is bad style because it ignores the user's interface preferences.

This is done all the time in other applications.  What's the point of
internationalization if you'd then need another function for each locale
and variant that the program intends to use?  That is exactly why
setlocale returns an object that you can use to restore the locale at
any point in time.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada






  reply	other threads:[~2012-09-22  6:19 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-09  7:37 bug#12392: 24.2; emacs-gtk misinterprets floating-point numbers under certain locales on openSUSE 12.2 Achim Gratz
2012-09-09  7:43 ` Achim Gratz
2012-09-09  8:09 ` Achim Gratz
2012-09-09  8:30 ` Achim Gratz
2012-09-10 17:37   ` Jan Djärv
2012-09-10 19:00     ` Achim Gratz
2012-09-13  8:20 ` bug#12392: " Paul Eggert
2012-09-13 17:59   ` Achim Gratz
2012-09-14 15:58   ` Achim Gratz
2012-09-21  9:59   ` Holger Arnold
2012-09-22  6:19     ` Achim Gratz [this message]
2012-09-22 14:38       ` Holger Arnold
2012-09-22 15:08         ` Andreas Schwab
2012-09-22 15:49           ` Holger Arnold
2012-09-22 16:07             ` Eli Zaretskii
2012-09-22 17:04               ` Holger Arnold
2012-09-22 17:19                 ` Jan Djärv
2012-09-22 17:22                   ` Jan Djärv
2012-09-22 16:54             ` Jan Djärv
2012-09-22 16:55               ` Jan Djärv
2012-09-22 17:00                 ` Holger Arnold
2012-09-23 10:04                   ` Jan Djärv
2012-09-23 17:27                 ` Achim Gratz
2012-09-23 19:58                   ` Holger Arnold
2012-09-22 16:56               ` Holger Arnold
2012-09-22 16:02         ` Eli Zaretskii
2012-09-22 16:38           ` Holger Arnold
2012-09-22 16:41             ` Eli Zaretskii
2012-09-22 16:54               ` Holger Arnold
2012-09-22 17:10                 ` Eli Zaretskii
2012-09-22 17:18                   ` Holger Arnold
2012-09-22 19:02                     ` Eli Zaretskii
2012-09-22 19:44                       ` Holger Arnold
2012-09-22 16:36         ` Achim Gratz
2012-10-07 10:57           ` Holger Arnold
2012-09-21 20:08   ` Holger Arnold

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=87zk4ifukb.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=12392@debbugs.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).