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

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

bug#12392: emacs-gtk misinterprets floating-point numbers under certain


From: Achim Gratz
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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

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 via email to

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