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

Re: Solution for the problem of gvimext in UTF-8 locale

Expand Messages
  • Bram Moolenaar
    ... The libiconv.dll is big. I noticed one that is almost 1 Mbyte. While Win32 has native support for encoding conversions, thus mostly there is no reason to
    Message 1 of 9 , Jul 30, 2007
    • 0 Attachment
      Taro Muraoka wrote:

      > Vim loads libintl.dll dynamically, so we can try multiple
      > implementations of libintl.dll easily.
      >
      > In attached patch, it try to load libintl2.dll (which requres
      > libiconv.dll too) first, when it was failed, try to load libintl.dll
      > (not require libiconv.dll). After applied this patch, we would
      > distribute libintl2.dll and libiconv.dll separately from vim as an
      > "option".

      The libiconv.dll is big. I noticed one that is almost 1 Mbyte. While
      Win32 has native support for encoding conversions, thus mostly there is
      no reason to use libiconv.dll. Conversions not natively supported are
      likely to have problems anyway.

      The libintl.dll that's included with the big self-installing Vim is a
      bit old. I hesitate to replace it, because it should work with all
      different compilers.

      Is the problem that the ports of GNU gettext to Win32 have not been
      modified to use the Win32 API?

      --
      hundred-and-one symptoms of being an internet addict:
      56. You leave the modem speaker on after connecting because you think it
      sounds like the ocean wind...the perfect soundtrack for "surfing the net".

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_multibyte" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • MURAOKA Taro
      Hi Bram. I see 3 items to think in your reply: 1. Should vim continue to use iconv.dll? 2. Is the newer libintl.dll portable? 3. Can we modify gettext to use
      Message 2 of 9 , Jul 30, 2007
      • 0 Attachment
        Hi Bram.


        I see 3 items to think in your reply:
        1. Should vim continue to use iconv.dll?
        2. Is the newer libintl.dll portable?
        3. Can we modify gettext to use Windows native converter?
        I'll answer one by one.


        = 1. Should vim continue to use iconv.dll? =

        YES. Count of encodings which Windows support is different depends on
        edition or installed other modules. Ex:Vista has large number of
        encodings support, but 2000 has fewer. So it may become hard to
        warrant
        and provide enough number of encodings to real users who need encoding
        conversion.


        = 2. Is the newer libintl.dll portable? =

        YES. I have tried to compile a newer gettext (0.14.2) by MSVC 7.1.
        And it have succeeded.


        = 3. Can we modify gettext to use Windows native converter? =

        YES. It will be a work to implement another iconv implementation by
        using Windows native encoding converter. And vim will become a
        important example at the moment, to creating a patch.
        BUT, I think it is not easy to be applied the patch by the gettext
        maintainer. If it isn't applied, we must maintain and release
        branched gettext codes.
        --
        MURAOKA Taro <KoRoN.KaoriYa@...>


        On 7月31日, 午前5:11, Bram Moolenaar <B...@...> wrote:
        > Taro Muraoka wrote:
        > > Vim loads libintl.dll dynamically, so we can try multiple
        > > implementations of libintl.dll easily.
        >
        > > In attached patch, it try to load libintl2.dll (which requres
        > > libiconv.dll too) first, when it was failed, try to load libintl.dll
        > > (not require libiconv.dll). After applied this patch, we would
        > > distribute libintl2.dll and libiconv.dll separately from vim as an
        > > "option".
        >
        > The libiconv.dll is big. I noticed one that is almost 1 Mbyte. While
        > Win32 has native support for encoding conversions, thus mostly there is
        > no reason to use libiconv.dll. Conversions not natively supported are
        > likely to have problems anyway.
        >
        > The libintl.dll that's included with the big self-installing Vim is a
        > bit old. I hesitate to replace it, because it should work with all
        > different compilers.
        >
        > Is the problem that the ports of GNU gettext to Win32 have not been
        > modified to use the Win32 API?
        >
        > --
        > hundred-and-one symptoms of being an internet addict:
        > 56. You leave the modem speaker on after connecting because you think it
        > sounds like the ocean wind...the perfect soundtrack for "surfing the net".
        >
        > /// Bram Moolenaar -- B...@... --http://www.Moolenaar.net \\\
        > /// sponsor Vim, vote for features --http://www.Vim.org/sponsor/\\\
        > \\\ download, build and distribute --http://www.A-A-P.org ///
        > \\\ help me help AIDS victims --http://ICCF-Holland.org ///


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_multibyte" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Rainux
        Wonderful answer! Yes, I think the problem that Vim can not handle ucs-2le encoding file I ve encoutered, is produced by the problem of native encoding
        Message 3 of 9 , Jul 31, 2007
        • 0 Attachment
          Wonderful answer!

          Yes, I think the problem that Vim can not handle ucs-2le encoding file
          I've encoutered, is produced by the problem of native encoding
          conversion in Win32.

          On 7/31/07, MURAOKA Taro <KoRoN.KaoriYa@...> wrote:
          >
          > Hi Bram.
          >
          >
          > I see 3 items to think in your reply:
          > 1. Should vim continue to use iconv.dll?
          > 2. Is the newer libintl.dll portable?
          > 3. Can we modify gettext to use Windows native converter?
          > I'll answer one by one.
          >
          >
          > = 1. Should vim continue to use iconv.dll? =
          >
          > YES. Count of encodings which Windows support is different depends on
          > edition or installed other modules. Ex:Vista has large number of
          > encodings support, but 2000 has fewer. So it may become hard to
          > warrant
          > and provide enough number of encodings to real users who need encoding
          > conversion.
          >
          >
          > = 2. Is the newer libintl.dll portable? =
          >
          > YES. I have tried to compile a newer gettext (0.14.2) by MSVC 7.1.
          > And it have succeeded.
          >
          >
          > = 3. Can we modify gettext to use Windows native converter? =
          >
          > YES. It will be a work to implement another iconv implementation by
          > using Windows native encoding converter. And vim will become a
          > important example at the moment, to creating a patch.
          > BUT, I think it is not easy to be applied the patch by the gettext
          > maintainer. If it isn't applied, we must maintain and release
          > branched gettext codes.
          > --
          > MURAOKA Taro <KoRoN.KaoriYa@...>
          >
          >
          > On 7月31日, 午前5:11, Bram Moolenaar <B...@...> wrote:
          > > Taro Muraoka wrote:
          > > > Vim loads libintl.dll dynamically, so we can try multiple
          > > > implementations of libintl.dll easily.
          > >
          > > > In attached patch, it try to load libintl2.dll (which requres
          > > > libiconv.dll too) first, when it was failed, try to load libintl.dll
          > > > (not require libiconv.dll). After applied this patch, we would
          > > > distribute libintl2.dll and libiconv.dll separately from vim as an
          > > > "option".
          > >
          > > The libiconv.dll is big. I noticed one that is almost 1 Mbyte. While
          > > Win32 has native support for encoding conversions, thus mostly there is
          > > no reason to use libiconv.dll. Conversions not natively supported are
          > > likely to have problems anyway.
          > >
          > > The libintl.dll that's included with the big self-installing Vim is a
          > > bit old. I hesitate to replace it, because it should work with all
          > > different compilers.
          > >
          > > Is the problem that the ports of GNU gettext to Win32 have not been
          > > modified to use the Win32 API?
          > >
          > > --
          > > hundred-and-one symptoms of being an internet addict:
          > > 56. You leave the modem speaker on after connecting because you think it
          > > sounds like the ocean wind...the perfect soundtrack for "surfing the net".
          > >
          > > /// Bram Moolenaar -- B...@... --http://www.Moolenaar.net \\\
          > > /// sponsor Vim, vote for features --http://www.Vim.org/sponsor/\\\
          > > \\\ download, build and distribute --http://www.A-A-P.org ///
          > > \\\ help me help AIDS victims --http://ICCF-Holland.org ///
          >
          >
          > >
          >


          --
          Best Regards

          Rainux

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_multibyte" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Bram Moolenaar
          ... What is your encoding set to then? Win32 has reasonable Unicode support, and Vim does some conversion itself too. Thus this would only fail if your
          Message 4 of 9 , Jul 31, 2007
          • 0 Attachment
            Rainux wrote:

            > Wonderful answer!
            >
            > Yes, I think the problem that Vim can not handle ucs-2le encoding file
            > I've encoutered, is produced by the problem of native encoding
            > conversion in Win32.

            What is your 'encoding' set to then? Win32 has reasonable Unicode
            support, and Vim does some conversion itself too. Thus this would only
            fail if your 'encoding' is set to something that MS-Windows doesn't
            support.

            It might be that your 'fileencodings' setting has a wrong value.

            --
            hundred-and-one symptoms of being an internet addict:
            70. ISDN lines are added to your house on a hourly basis

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_multibyte" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Bram Moolenaar
            ... We rarely remove existing support. However, keep in mind that iconv is loaded dynamically, it s only really loaded when the user has it installed in the
            Message 5 of 9 , Jul 31, 2007
            • 0 Attachment
              Taro Muraoka wrote:

              > I see 3 items to think in your reply:
              > 1. Should vim continue to use iconv.dll?
              > 2. Is the newer libintl.dll portable?
              > 3. Can we modify gettext to use Windows native converter?
              > I'll answer one by one.
              >
              >
              > = 1. Should vim continue to use iconv.dll? =
              >
              > YES. Count of encodings which Windows support is different depends on
              > edition or installed other modules. Ex:Vista has large number of
              > encodings support, but 2000 has fewer. So it may become hard to
              > warrant
              > and provide enough number of encodings to real users who need encoding
              > conversion.

              We rarely remove existing support. However, keep in mind that iconv is
              loaded dynamically, it's only really loaded when the user has it
              installed in the path. It's not included in the Vim distribution, so
              it's actally rare that people use it. Most people rely on the Windows
              conversion functionality. But you can add the iconv library when you
              need it.

              > = 2. Is the newer libintl.dll portable? =
              >
              > YES. I have tried to compile a newer gettext (0.14.2) by MSVC 7.1.
              > And it have succeeded.

              I wasn't talking about the source code being portable. I was wondering
              if the binary libintl.dll is portable. That means it works no matter
              with which compiler Vim was compiled. And it doesn't require any other
              library. That's how it works at the moment. In the past there have
              been problems that a dll compiled with compiler X does not work with Vim
              compiled with compiler Y. That defeats the idea of independent
              libraries.

              > = 3. Can we modify gettext to use Windows native converter? =
              >
              > YES. It will be a work to implement another iconv implementation by
              > using Windows native encoding converter. And vim will become a
              > important example at the moment, to creating a patch.
              > BUT, I think it is not easy to be applied the patch by the gettext
              > maintainer. If it isn't applied, we must maintain and release
              > branched gettext codes.

              So the libintl.dll that supports more encodings requires iconv, it
              doesn't use the Windows native conversions? And if we want it otherwise
              we need to build our own libintl.dll?

              It's not surprising, actually, that people somehow accept having to
              install a 1 Mbyte library just to make a 50 Kbyte library work (and then
              probably not use the features that the 1 Mbyte library offers). It
              sounds like work was saved by not converting the library to MS-Windows.

              I think the best solution would be that gettext (libintl.dll) tries to
              dynamically load iconv, then when that fails falls back to using the
              Windows native conversion functions. The first part should be
              relatively easy to implement, then we at least have a backwards
              compatible version of libintl.dll, not requiring the 1 Mbyte
              libiconv.dll (and people who need the iconv functionality can get it).
              The second part might be a bit more work.

              --
              hundred-and-one symptoms of being an internet addict:
              66. You create a homepage with the impression to cure the afflicted...but
              your hidden agenda is to receive more e-mail.

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ download, build and distribute -- http://www.A-A-P.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_multibyte" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Rainux
              This is the relative settings in my .vimrc set fileencodings=ucs-bom,utf-8,chinese set encoding=utf-8 I m sorry now I can not recur that problem, it not occur
              Message 6 of 9 , Jul 31, 2007
              • 0 Attachment
                This is the relative settings in my .vimrc

                set fileencodings=ucs-bom,utf-8,chinese
                set encoding=utf-8

                I'm sorry now I can not recur that problem, it not occur on all Win32
                environment.

                Sorry for the repeat, I just forgot to "Reply to all".

                On 8/1/07, Bram Moolenaar <Bram@...> wrote:
                >
                > Rainux wrote:
                >
                > > Wonderful answer!
                > >
                > > Yes, I think the problem that Vim can not handle ucs-2le encoding file
                > > I've encoutered, is produced by the problem of native encoding
                > > conversion in Win32.
                >
                > What is your 'encoding' set to then? Win32 has reasonable Unicode
                > support, and Vim does some conversion itself too. Thus this would only
                > fail if your 'encoding' is set to something that MS-Windows doesn't
                > support.
                >
                > It might be that your 'fileencodings' setting has a wrong value.
                >
                > --
                > hundred-and-one symptoms of being an internet addict:
                > 70. ISDN lines are added to your house on a hourly basis
                >
                > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                > \\\ download, build and distribute -- http://www.A-A-P.org ///
                > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
                >


                --
                Best Regards

                Rainux

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_multibyte" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              Your message has been successfully submitted and would be delivered to recipients shortly.