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

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

Expand Messages
  • Thilo Six
    Tony Mechelynck wrote the following on 03.10.2011 06:03 -- -- ... -- -- ... -- -- ... I suspect without explictly testing it those two are
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.