From: Holger Arnold <holgerar@gmail.com>
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 16:38:22 +0200 [thread overview]
Message-ID: <1544800.869GeMQOQf@thinkpad.home> (raw)
In-Reply-To: <87zk4ifukb.fsf@Rainer.invalid>
Achim Gratz wrote:
> 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.
May I cite: "Note, however, that changing the locale after GTK+ is initialized
may produce inconsistent results and is not really supported." This warning
is not related to this particular function, as gtk_set_locale() does nothing
more than calling setlocale(LC_ALL, ""). Emacs calls this function via
gtk_init().
> > 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.
I don't know which are the things that are wrong with internationalization you
are referring to, but, IMHO, setting the locale or parts of it to a value
different from what the user has specified is the wrong approach. Lisp
programs are simply not localizable text.
> > 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.
To me, the warning cited above sounds sufficiently explicit.
Note that _any_ program having a localized user interface has to call
setlocale(LC_ALL, "") at the start to set the locale to the value specified by
its environment. gtk_init() simply does this for you. If you don't like that
behavior, you can initialize GTK without calling gtk_init() (but this wouldn't
help with GStreamer).
As to whether calling setlocale(LC_ALL, "") in a library is a bug, what would
you expect a library that wants to provide localized messages to do? Changing
the locale before and after each call? This would be racy in a multi-threaded
program.
> > 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.
And calling gtk_disable_setlocale() wouldn't help anyway.
> > 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.
I know that many programs do it that way, but this does not make it the
correct approach. Programs that reset (parts of) the locale to "C" have been
developed under the idea that the program "owns" the locale and can manipulate
it at will. In my -- extremely humble -- opinion, that is a misconception of
the locale concept. Locales provide a way for *users* to specify their
preferences wrt. localization. Therefore, the current locale belongs to the
*user*, and a localized program should not manipulate it beyond calling
setlocale(LC_ALL, ""), which is basically just an alias for "yes, I want to be
localized".
Now, what can programs do that have to manipulate text in multiple locales?
If you have complete control over everything, you can indeed switch the
current locale before and after each call to an input, output, conversion, or
string manipulation function. If you have multiple threads, don't forget to
properly synchronize these calls. The problem is that this is inefficient and
that you _don't have_ complete control in a program that interacts with many
components, like Emacs does. Do you want to race with GTK, GStreamer, or
whatever library over the current locale?
The better approach would be to have input, output, conversion, and string
manipulation functions that take a locale as an additional argument, similarly
to the C++ standard lib, where each stream has an assigned locale. Since the
code is already there, it would be an easy task to add such functions to glibc
(but this is probably not going to happen).
But for Emacs and most other programs, this isn't even needed. Most programs
manipulate only two kinds of text: user interface text, which should be
processed in the locale specified by the environment, and formal language
text, such as configuration files or program code, which should be processed
independently from the locale.
So, the only thing that has to be done for Emacs is to make all functions that
print or parse Lisp objects locale-independent (yes, this means you can't use
atof() for converting a number). This isn't too hard.
The other option would be to simply ignore localization and start Emacs always
with LANG=C.
Holger
next prev parent reply other threads:[~2012-09-22 14:38 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
2012-09-22 14:38 ` Holger Arnold [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1544800.869GeMQOQf@thinkpad.home \
--to=holgerar@gmail.com \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.