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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.