From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Holger Arnold Newsgroups: gmane.emacs.bugs 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 Message-ID: <1544800.869GeMQOQf@thinkpad.home> References: <87r4qbodec.fsf@Rainer.invalid> <87zk4ifukb.fsf@Rainer.invalid> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1348324776 30606 80.91.229.3 (22 Sep 2012 14:39:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Sep 2012 14:39:36 +0000 (UTC) To: 12392@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 22 16:39:37 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TFQrn-0004ad-Kn for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Sep 2012 16:39:35 +0200 Original-Received: from localhost ([::1]:58061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TFQrj-0003uW-1l for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Sep 2012 10:39:31 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:44781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TFQrc-0003tO-Fz for bug-gnu-emacs@gnu.org; Sat, 22 Sep 2012 10:39:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TFQrY-0004zG-Ak for bug-gnu-emacs@gnu.org; Sat, 22 Sep 2012 10:39:24 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TFQrY-0004zB-6j for bug-gnu-emacs@gnu.org; Sat, 22 Sep 2012 10:39:20 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TFQtC-0005b5-IA for bug-gnu-emacs@gnu.org; Sat, 22 Sep 2012 10:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Holger Arnold Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Sep 2012 14:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12392 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 12392-submit@debbugs.gnu.org id=B12392.134832483421478 (code B ref 12392); Sat, 22 Sep 2012 14:41:02 +0000 Original-Received: (at 12392) by debbugs.gnu.org; 22 Sep 2012 14:40:34 +0000 Original-Received: from localhost ([127.0.0.1]:49190 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFQsW-0005aA-7p for submit@debbugs.gnu.org; Sat, 22 Sep 2012 10:40:24 -0400 Original-Received: from mail-bk0-f44.google.com ([209.85.214.44]:41675) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TFQsM-0005Zu-7X for 12392@debbugs.gnu.org; Sat, 22 Sep 2012 10:40:15 -0400 Original-Received: by bkty12 with SMTP id y12so2216387bkt.3 for <12392@debbugs.gnu.org>; Sat, 22 Sep 2012 07:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; bh=xjE6x11+LGIqVMClZNqW/BVCIC81T3Bk/iiTxLpPuSc=; b=kPctFOYL6XSVrTHF9QU1OAfLJP5NR4vBmj9Zv4HvvxFcr19FJbFggSjK6IiZw+b3I8 /5Mgd2UTVzVZ8DRmlJ+oiasQP8MDtrqS8dRa8m6nndPPZKTMP2nijSYKlZus1MBWCSY2 2PAtG4w1V+swEPfiBdOIAjNUlp1fr7B2MyH8upaZD274KVDF3vTzpQtluHo02BRcinJh FTwsB+zTEVCsYCCPy2q6OTLyAJoE/L68i5buTwVozsMlDdP18vr1PjCuK5tnTy5fsOA3 zInQhW9o6nsnzTJcY27/8zCt15s9ZZYsOXm9pvk6HDqYG8OUElkpLBX8wKCneS8Bqp2j VJTQ== Original-Received: by 10.204.136.216 with SMTP id s24mr3310547bkt.137.1348324706433; Sat, 22 Sep 2012 07:38:26 -0700 (PDT) Original-Received: from thinkpad.home ([77.64.254.200]) by mx.google.com with ESMTPS id n5sm7679506bkv.14.2012.09.22.07.38.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Sep 2012 07:38:25 -0700 (PDT) User-Agent: KMail/4.9.1 (Linux/3.5.4-1-default; KDE/4.9.1; i686; ; ) In-Reply-To: <87zk4ifukb.fsf@Rainer.invalid> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64743 Archived-At: 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