Loading ...
Sorry, an error occurred while loading the content.

Bug or feature? $LC_NUMERIC not set to "C"

Expand Messages
  • Tony Mechelynck
    My gvim (7.3.329) is compiled with +float. My environment contains $LANG=en_US.UTF-8 $LANGUAGE= $LC_PAPER=en_GB $LC_TIME=en_GB no other $LC_something My vimrc
    Message 1 of 13 , Oct 1, 2011
    • 0 Attachment
      My gvim (7.3.329) is compiled with +float.
      My environment contains
      $LANG=en_US.UTF-8
      $LANGUAGE=
      $LC_PAPER=en_GB
      $LC_TIME=en_GB
      no other $LC_something
      My vimrc sets
      language messages C
      language time en_GB
      But contrary to what is said in the help (currently at line 78 of
      mlang.txt, one page or so below :help :lang), $LC_NUMERIC (as seen in
      the output of :lang with no arguments) is not set at C, it remains at
      en_US.UTF-8 (implicitly from $LANG I suppose).

      In this case it doesn't matter since the decimal point for en_US is the
      period. But I wonder what would have happened in a French locale (where
      the "decimal-point is comma" convention is /de rigueur/).


      Best regards,
      Tony.
      --
      You can take all the impact that science considerations have on funding
      decisions at NASA, put them in the navel of a flea, and have room left
      over for a caraway seed and Tony Calio's heart.
      -- F. Allen

      --
      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
    • Bram Moolenaar
      ... Vim does explicitly set LC_NUMERIC to C . And that s what happens for me. I can t guess why it s different for you. -- Everyone has a photographic
      Message 2 of 13 , Oct 2, 2011
      • 0 Attachment
        Tony Mechelynck wrote:

        > My gvim (7.3.329) is compiled with +float.
        > My environment contains
        > $LANG=en_US.UTF-8
        > $LANGUAGE=
        > $LC_PAPER=en_GB
        > $LC_TIME=en_GB
        > no other $LC_something
        > My vimrc sets
        > language messages C
        > language time en_GB
        > But contrary to what is said in the help (currently at line 78 of
        > mlang.txt, one page or so below :help :lang), $LC_NUMERIC (as seen in
        > the output of :lang with no arguments) is not set at C, it remains at
        > en_US.UTF-8 (implicitly from $LANG I suppose).
        >
        > In this case it doesn't matter since the decimal point for en_US is the
        > period. But I wonder what would have happened in a French locale (where
        > the "decimal-point is comma" convention is /de rigueur/).

        Vim does explicitly set LC_NUMERIC to "C". And that's what happens for
        me. I can't guess why it's different for you.

        --
        Everyone has a photographic memory. Some don't have film.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        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
      • Tony Mechelynck
        ... Neither can I; but adding a few :echomsg commands shows the following: - $LC_NUMERIC is C on entry to the vimrc - it is still C while sourcing the last
        Message 3 of 13 , Oct 2, 2011
        • 0 Attachment
          On 02/10/11 22:25, Bram Moolenaar wrote:
          >
          > Tony Mechelynck wrote:
          >
          >> My gvim (7.3.329) is compiled with +float.
          >> My environment contains
          >> $LANG=en_US.UTF-8
          >> $LANGUAGE=
          >> $LC_PAPER=en_GB
          >> $LC_TIME=en_GB
          >> no other $LC_something
          >> My vimrc sets
          >> language messages C
          >> language time en_GB
          >> But contrary to what is said in the help (currently at line 78 of
          >> mlang.txt, one page or so below :help :lang), $LC_NUMERIC (as seen in
          >> the output of :lang with no arguments) is not set at C, it remains at
          >> en_US.UTF-8 (implicitly from $LANG I suppose).
          >>
          >> In this case it doesn't matter since the decimal point for en_US is the
          >> period. But I wonder what would have happened in a French locale (where
          >> the "decimal-point is comma" convention is /de rigueur/).
          >
          > Vim does explicitly set LC_NUMERIC to "C". And that's what happens for
          > me. I can't guess why it's different for you.
          >

          Neither can I; but adding a few :echomsg commands shows the following:

          - $LC_NUMERIC is "C" on entry to the vimrc
          - it is still "C" while sourcing the last global after-plugin
          - it has become empty (and is listed as "en_US.UTF-8" in the output of
          :lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
          - it remains set to "C" if I run the same Vim executable in console mode.

          I suspect the line marked below with <----- at line 1467 of main.c but I
          don't know GTK well enough to be sure. Do you think it would be worth
          swapping the two ifdef blocks to see if it changes anything? (Not this
          second, I'm going to bed.)

          /*
          * Setup to use the current locale (for ctype() and many other things).
          */
          static void
          init_locale()
          {
          setlocale(LC_ALL, "");

          # ifdef FEAT_GUI_GTK
          /* Tell Gtk not to change our locale settings. */
          gtk_disable_setlocale(); <----- this line
          # endif
          # if defined(FEAT_FLOAT) && defined(LC_NUMERIC)
          /* Make sure strtod() uses a decimal point, not a comma. */
          setlocale(LC_NUMERIC, "C");
          # endif


          Best regards,
          Tony.
          --
          hundred-and-one symptoms of being an internet addict:
          192. Your boss asks you to "go fer" coffee and you come up with 235 FTP
          sites.

          --
          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
        • Thilo Six
          Tony Mechelynck wrote the following on 03.10.2011 06:03 -- -- ... -- -- ... -- -- ... I suspect without explictly testing it those two are
          Message 4 of 13 , Oct 3, 2011
          • 0 Attachment
            Tony Mechelynck wrote the following on 03.10.2011 06:03

            -- <snip> --

            >>> $LANGUAGE=

            -- <snip> --

            > - it has become empty (and is listed as "en_US.UTF-8" in the output of
            > :lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
            > - it remains set to "C" if I run the same Vim executable in console mode.

            -- <snip> --

            > Best regards,
            > Tony.

            I suspect without explictly testing it those two are related. If you don´t want
            '$LANGUAGE' one has to use 'unset LANGUAGE' (there may differences about the
            specific syntax to use depending on the shell you use). But setting it to an
            empty value isn´t the same.

            Regards,
            --
            bye Thilo

            4096R/0xC70B1A8F
            721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F


            --
            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
          • Tony Mechelynck
            On 03/10/11 06:03, Tony Mechelynck wrote: [...] ... After swapping them, $LC_NUMERIC is still reset at GUIEnter ... -- The first myth of management is that it
            Message 5 of 13 , Oct 3, 2011
            • 0 Attachment
              On 03/10/11 06:03, Tony Mechelynck wrote:
              [...]
              > - $LC_NUMERIC is "C" on entry to the vimrc
              > - it is still "C" while sourcing the last global after-plugin
              > - it has become empty (and is listed as "en_US.UTF-8" in the output of
              > :lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
              > - it remains set to "C" if I run the same Vim executable in console mode.
              >
              > I suspect the line marked below with <----- at line 1467 of main.c but I
              > don't know GTK well enough to be sure. Do you think it would be worth
              > swapping the two ifdef blocks to see if it changes anything? (Not this
              > second, I'm going to bed.)

              After swapping them, $LC_NUMERIC is still reset at GUIEnter

              >
              > /*
              > * Setup to use the current locale (for ctype() and many other things).
              > */
              > static void
              > init_locale()
              > {
              > setlocale(LC_ALL, "");
              >
              > # ifdef FEAT_GUI_GTK
              > /* Tell Gtk not to change our locale settings. */
              > gtk_disable_setlocale(); <----- this line
              > # endif
              > # if defined(FEAT_FLOAT) && defined(LC_NUMERIC)
              > /* Make sure strtod() uses a decimal point, not a comma. */
              > setlocale(LC_NUMERIC, "C");
              > # endif
              >
              >
              > Best regards,
              > Tony.
              --
              The first myth of management is that it exists. The second myth of
              management is that success equals skill.
              -- Robert Heller

              --
              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
            • Tony Mechelynck
              ... I use bash; but the problem is not how to change my shell startup scripts, it s how to change Vim to make sure $LC_NUMERIC remains set at C after GUI
              Message 6 of 13 , Oct 3, 2011
              • 0 Attachment
                On 03/10/11 10:58, Thilo Six wrote:
                > Tony Mechelynck wrote the following on 03.10.2011 06:03
                >
                > -- <snip> --
                >
                >>>> $LANGUAGE=
                >
                > -- <snip> --
                >
                >> - it has become empty (and is listed as "en_US.UTF-8" in the output of
                >> :lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
                >> - it remains set to "C" if I run the same Vim executable in console mode.
                >
                > -- <snip> --
                >
                >> Best regards,
                >> Tony.
                >
                > I suspect without explictly testing it those two are related. If you don´t want
                > '$LANGUAGE' one has to use 'unset LANGUAGE' (there may differences about the
                > specific syntax to use depending on the shell you use). But setting it to an
                > empty value isn´t the same.
                >
                > Regards,

                I use bash; but the problem is not how to change my shell startup
                scripts, it's how to change Vim to make sure $LC_NUMERIC remains set at
                C after GUI startup for the full duration of the gvim process,
                regardless of what might have been in the outside environment outside of
                Vim.

                AFAICT, $LANGUAGE and $LC_ALL being set at the empty string has the same
                effect as them not being defined; in particular, after requesting the
                environment values of the locale settings, Vim sees them as they are set
                (most of them "en_US.UTF-8" from $LANG; $LC_TIME and $LC_PAPER "en_GB"
                for DD/MM/YY date and A4 paper), not everything empty. In C,
                setlocale(LC_ALL, "") explicitly means "set the locale settings from the
                environment, don't keep them all at 'C' which is mandated at program
                startup by the C standard", cf. the info page for setlocale.

                And BTW the problem happens only in the GUI; as I already mentioned, the
                same Vim executable keeps $LC_NUMERIC == 'C' when run in console mode.


                Best regards,
                Tony.
                --
                hundred-and-one symptoms of being an internet addict:
                193. You ask your girlfriend to drive home so you can sit back with
                your PDA and download the information to your laptop

                --
                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
              • Thilo Six
                Tony Mechelynck wrote the following on 03.10.2011 16:33 -- -- ... -- -- ... -- -- afaict it is not. ymmv. Once on a manual page i read
                Message 7 of 13 , Oct 3, 2011
                • 0 Attachment
                  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,

                  --
                  bye Thilo

                  4096R/0xC70B1A8F
                  721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F


                  --
                  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
                • Dennis Benzinger
                  ... It s documented as an info document. Try: info gettext Locale Environment Variables info gettext The LANGUAGE variable HTH, Dennis Benzinger -- You
                  Message 8 of 13 , Oct 3, 2011
                  • 0 Attachment
                    Am 03.10.2011 18:37, schrieb Thilo Six:
                    > 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.
                    > [...]

                    It's documented as an info document. Try:

                    info gettext 'Locale Environment Variables'
                    info gettext 'The LANGUAGE variable'


                    HTH,
                    Dennis Benzinger

                    --
                    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
                  • Tony Mechelynck
                    ... $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
                    Message 9 of 13 , Oct 3, 2011
                    • 0 Attachment
                      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
                    • Tony Mechelynck
                      ... In addition to my scientific experiments mentioned in the other post, I have the dogmatic reference to the standard, and it confirms what I found: in
                      Message 10 of 13 , Oct 3, 2011
                      • 0 Attachment
                        On 04/10/11 01:06, Tony Mechelynck wrote:
                        > 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.

                        In addition to my "scientific" experiments mentioned in the other post,
                        I have the "dogmatic" reference to the standard, and it confirms what I
                        found: in

                        info gettext 'Locale Environment Variables'

                        I see the following:

                        Variables whose value is set but is empty are ignored in this lookup.



                        Best regards,
                        Tony.
                        --
                        If bankers can count, how come they have eight windows and only four
                        tellers?

                        --
                        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
                      • Bram Moolenaar
                        ... I hope you are not checking the $LC_NUMERIC environment variable, it is only used when calling setlocale(), not by the library functions where the value of
                        Message 11 of 13 , Oct 4, 2011
                        • 0 Attachment
                          Tony Mechelynck wrote:

                          > > Vim does explicitly set LC_NUMERIC to "C". And that's what happens for
                          > > me. I can't guess why it's different for you.
                          > >
                          >
                          > Neither can I; but adding a few :echomsg commands shows the following:
                          >
                          > - $LC_NUMERIC is "C" on entry to the vimrc
                          > - it is still "C" while sourcing the last global after-plugin
                          > - it has become empty (and is listed as "en_US.UTF-8" in the output of
                          > :lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
                          > - it remains set to "C" if I run the same Vim executable in console mode.
                          >
                          > I suspect the line marked below with <----- at line 1467 of main.c but I
                          > don't know GTK well enough to be sure. Do you think it would be worth
                          > swapping the two ifdef blocks to see if it changes anything? (Not this
                          > second, I'm going to bed.)
                          >
                          > /*
                          > * Setup to use the current locale (for ctype() and many other things).
                          > */
                          > static void
                          > init_locale()
                          > {
                          > setlocale(LC_ALL, "");
                          >
                          > # ifdef FEAT_GUI_GTK
                          > /* Tell Gtk not to change our locale settings. */
                          > gtk_disable_setlocale(); <----- this line
                          > # endif
                          > # if defined(FEAT_FLOAT) && defined(LC_NUMERIC)
                          > /* Make sure strtod() uses a decimal point, not a comma. */
                          > setlocale(LC_NUMERIC, "C");
                          > # endif

                          I hope you are not checking the $LC_NUMERIC environment variable, it is
                          only used when calling setlocale(), not by the library functions where
                          the value of the locale matters.

                          You need to use setlocale(LC_NUMERIC, NULL) to check the actual value.

                          --
                          Bumper sticker: Honk if you love peace and quiet.

                          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                          \\\ an exciting new programming language -- http://www.Zimbu.org ///
                          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                          --
                          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
                        • Thilo Six
                          Tony Mechelynck wrote the following on 04.10.2011 01:38 Hello Tony, -- -- ... I stand corrected. ... Regards, -- bye Thilo 4096R/0xC70B1A8F 721B 1BA0
                          Message 12 of 13 , Oct 4, 2011
                          • 0 Attachment
                            Tony Mechelynck wrote the following on 04.10.2011 01:38

                            Hello Tony,

                            -- <snip> --

                            > In addition to my "scientific" experiments mentioned in the other post,
                            > I have the "dogmatic" reference to the standard, and it confirms what I
                            > found: in
                            >
                            > info gettext 'Locale Environment Variables'
                            >
                            > I see the following:
                            >
                            > Variables whose value is set but is empty are ignored in this lookup.

                            I stand corrected.

                            >
                            > Best regards,
                            > Tony.


                            Regards,
                            --
                            bye Thilo

                            4096R/0xC70B1A8F
                            721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F


                            --
                            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
                          • Tony Mechelynck
                            ... Swapping the blocks didn t change anything. I remain with the observation that, in gvim with GTK2/Gnome2 GUI, $LC_NUMERIC is reset when starting the GUI,
                            Message 13 of 13 , Oct 6, 2011
                            • 0 Attachment
                              On 04/10/11 14:52, Bram Moolenaar wrote:
                              >
                              > Tony Mechelynck wrote:
                              >
                              >>> Vim does explicitly set LC_NUMERIC to "C". And that's what happens for
                              >>> me. I can't guess why it's different for you.
                              >>>
                              >>
                              >> Neither can I; but adding a few :echomsg commands shows the following:
                              >>
                              >> - $LC_NUMERIC is "C" on entry to the vimrc
                              >> - it is still "C" while sourcing the last global after-plugin
                              >> - it has become empty (and is listed as "en_US.UTF-8" in the output of
                              >> :lang with no arguments) at the GUIEnter event in gvim with GTK2/Gnome2 GUI
                              >> - it remains set to "C" if I run the same Vim executable in console mode.
                              >>
                              >> I suspect the line marked below with<----- at line 1467 of main.c but I
                              >> don't know GTK well enough to be sure. Do you think it would be worth
                              >> swapping the two ifdef blocks to see if it changes anything? (Not this
                              >> second, I'm going to bed.)
                              >>
                              >> /*
                              >> * Setup to use the current locale (for ctype() and many other things).
                              >> */
                              >> static void
                              >> init_locale()
                              >> {
                              >> setlocale(LC_ALL, "");
                              >>
                              >> # ifdef FEAT_GUI_GTK
                              >> /* Tell Gtk not to change our locale settings. */
                              >> gtk_disable_setlocale();<----- this line
                              >> # endif
                              >> # if defined(FEAT_FLOAT)&& defined(LC_NUMERIC)
                              >> /* Make sure strtod() uses a decimal point, not a comma. */
                              >> setlocale(LC_NUMERIC, "C");
                              >> # endif
                              >
                              > I hope you are not checking the $LC_NUMERIC environment variable, it is
                              > only used when calling setlocale(), not by the library functions where
                              > the value of the locale matters.
                              >
                              > You need to use setlocale(LC_NUMERIC, NULL) to check the actual value.
                              >

                              Swapping the blocks didn't change anything.

                              I remain with the observation that, in gvim with GTK2/Gnome2 GUI,
                              $LC_NUMERIC is reset when starting the GUI, as shown by the following
                              (when in gvim running in GUI mode):

                              - In the reply to :lang with no arguments, $LC_NUMERIC is set to the
                              default value, in my case en_US.UTF-8
                              - when invoking a shell from within gvim, set|more shows that
                              $LC_NUMERIC is not set

                              On the contrary, when running in console mode, $LC_NUMERIC is set to C
                              in the output of :lang but not in a subshell.

                              Running gvim in a "decimal-point is comma" locale, as follows (in bash):

                              LANG=fr_BE.UTF-8 gvim

                              gives the following:

                              :echo acos(0)
                              1,570796
                              (with a comma)

                              :echo 1.2 + 3.4
                              E806: using Float as a String
                              E15: Invalid expression: 1.2 + 3.4

                              :echo 1,2 + 3,4
                              1
                              E15: Invalid expression: ,2 + 3,4
                              E15: Invalid expression: ,2 + 3,4

                              while on my usual (en_US.UTF-8) locale the results are (in a different
                              instance of the same gvim executable)

                              :echo acos(0)
                              1.570796
                              (with a dot)

                              :echo 1.2 + 3.4
                              4.6

                              :echo 1,2 + 3,4
                              1
                              E15: Invalid expression: ,2 + 3,4
                              E15: Invalid expression: ,2 + 3,4

                              In console mode, the results are correct (as in en_US.UTF-8 gvim), even
                              in fr_BE.UTF-8 vim.


                              Best regards,
                              Tony.
                              --
                              If you're not part of the solution, you're part of the precipitate.

                              --
                              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
                            Your message has been successfully submitted and would be delivered to recipients shortly.