On 03/10/11 18:37, Thilo Six wrote:
Tony Mechelynck wrote the following on 03.10.2011 16:33
-- <snip> --
AFAICT, $LANGUAGE
-- <snip> --
being set at the empty string has the same
effect as them not being defined
-- <snip> --
afaict it is not. ymmv. Once on a manual page i read that '$LANGUAGE' takes
precedence over '$LANG' being set. Thats especially true for gui programs.
Sad bad true i can't find that particular manpage again right at hand.
But since you are the one who reported the problem it should be easy for you to
verify that my claims at your case are true or not.
Best regards,
Tony.
Regards,
$LC_ALL also takes precedence over not only $LANG but also all other
$LC_something. However, with my $LC_ALL and $LANGUAGE set to the empty
string, $LANG (the fallback) set to en_US.UTF-8, and $LC_TIME set to
en_GB, Vim sees all my LC_something variables the way I set them, and
SeaMonkey (another GTK2/Gnome2 GUI) uses the British convention
(DD/MM/YY) to display dates: thus neither an empty $LC_ALL nor an empty
$LANGUAGE overrides a nonempty $LC_TIME. If $LC_ALL were set to
something else than the empty string, that would take precedence. I
suppose that a *nonempty* $LANGUAGE would probably also take precedence,
but an empty one does not. This latter assertion of mine is not dogma,
it is science, i.o.w. it is not "The Book says" or "Thus spake the
Master", it is the result of a repeatable experiment.
Anyway, in a Vim script I cannot distinguish between an unset
environment variable and one which is set to the empty string: for instance
:echo ($FOOBAR == "")
returns 1, even though $FOOBAR is unset. Try it, you'll see.
But this $LANGUAGE vs. $LC_ALL vs. etc. vs. $LANG question is a side
issue which is not relevant to the problem, which is a Vim problem, not
a bash problem and not a system-configuration problem, namely, that at
GUI startup in gvim for GTK2/Gnome2 GUI with +float compiled-in,
$LC_NUMERIC does not always (in practice!) remain at the value "C" which
Vim has set, overriding anything in the locale, in order to make sure
that in the string representation of floating-point numbers, the decimal
point will always be a point and never a comma.
I notice the problem but it does not hurt me, because after GUI startup,
my $LC_NUMERIC is reliably unset, and the fallback is $LANG, which on my
system is "en_US.UTF-8", another locale which uses the point as decimal
point. But as I said in the opening post, if my $LANG had been set to,
let's say, fr_BE.UTF-8 (which is not ludicrous since French is my mother
language and Belgium my home country: in fact on one of my former
Windows systems the locale was set to "French_Belgium.1252"), I wonder
how floating point input and output would have been handled.
Best regards,
Tony.
--
Matter cannot be created or destroyed, nor can it be returned without a
receipt.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
