Re: emacs 23.1 font problem

[David Kastrup]

Gerhard <feldspat@gmx.net> writes:

>>> In GNU Emacs 23.1.90.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.3)
>>>  of 2010-01-08 on localhost
>>> Windowing system distributor `The X.Org Foundation', version
>>> 11.0.10605000 Important settings:
>>>   value of $LC_ALL: nil
>>>   value of $LC_COLLATE: de_DE.UTF-8
>>>   value of $LC_CTYPE: de_DE.UTF-8
>>>   value of $LC_MESSAGES: de_DE.UTF-8
>>>   value of $LC_MONETARY: fr_FR.UTF-8
>>>   value of $LC_NUMERIC: fr_FR.UTF-8
>>>   value of $LC_TIME: de_DE.UTF-8
>>>   value of $LANG: de_DE.UTF-8
>>>   value of $XMODIFIERS: @im=none
>>>   locale-coding-system: utf-8-unix
>>>   default enable-multibyte-characters: t
>> 
>> What happens when you start Emacs with
>> 
>> LC_NUMERIC=C emacs
>> 
>> ?
> Everything seems to work fine now, great!
>
> Am I right in supposing that this resets locales only for emacs, and
> that there should be no undesired side-effects elsewhere?

It will affect every program started from within Emacs as well.  I am
not clear what code is responsible for this: the problem is likely
because either scanf or printf or its equivalents use "," instead of "."
in numbers.

Whether this happens inside of Emacs proper or in GTK, I don't know.  In
general, you rarely want LC_NUMERIC to be different from "C" for
_anything_.  Programming languages and libraries and utilities break
because programmers hardly ever expect that the equivalent of
printf("%4.2f",3.0) would result in "3,00" in foreign locales.

I know that some versions of Ghostscript ceased being able to parse
numbers in PostScript programs in such locales.

So while the above invocation is just for Emacs and subprocesses, your
setting of LC_NUMERIC is likely going to cause trouble occasionally also
elsewhere.  And why you would want French monetary expressions in a
German locale also escapes me.

-- 
David Kastrup