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

Re: New patch against 6.0q, for 'filewriteable' and 'iconv'

Expand Messages
  • Bram Moolenaar
    ... The character encoding name is standardized in several ways. There are several variants of iconv() around that only implement a subset. I m afraid that
    Message 1 of 5 , Dec 28, 2000
      Ron Aaron wrote:

      > >> and new:
      > >> - iconv() function.
      > >>
      > >> The iconv() function is used like this:
      > >>
      > >> let s = iconv('koi-8r', 'utf-8', getline('.'))
      > >>
      > >> for example ...
      > >>
      > >> Very nice for those of us who might need to convert a *string* or two but
      > >> not necessarily an entire buffer. It is only available if you
      > >> HAVE_ICONV...
      > >
      > >Can you explain where you would use this? I rather not include more
      > >functionality unless it's really clear we need it. Also because a function
      > >like this tends to grow bigger once it's there (I can already see a few
      > >things that need improvement, for example trying variants of the character
      > >set names).
      >
      > Well, the functionality is mostly inside libiconv; but I can see where you
      > might like variants of the name (as you do for file reads).

      The character encoding name is standardized in several ways. There are
      several variants of iconv() around that only implement a subset. I'm afraid
      that using an extra translation inside Vim is required.

      > I would use this whenever I have to look at multiply encoded files; for
      > example, 8859-8 in one part, 8859-2 in another (yes, I have such
      > monstrosities). Or in deciphering parts of messages, where the whole thing
      > isn't one encoding. I'm sure I can think of other uses... Oh, how about
      > converting the value from input() into utf-8 ...

      When you are working in UTF-8, input() should also get an UTF-8 string.
      Setting 'charcode' has the effect of everything inside Vim using that encoding
      (registers, variables, etc.). That's the only way I can see it work properly.

      When you are using different 8-bit encodings, you indeed quickly run into
      problems. Switching to UTF-8 should be a solution then.

      Manually translating betweeen different encodings might be a quick solution in
      specific situations, but it leads to a mess when used regularly. That's why
      Unicode was invented.

      You could also convert with the external iconv program. It's slower, but
      should be sufficient when using it ocasionally. So, what are the situations
      you really need an iconv() function inside Vim?

      --
      hundred-and-one symptoms of being an internet addict:
      128. You can access the Net -- via your portable and cellular phone.

      /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
      ((( Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim )))
      \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
    • Ron Aaron (Comforce/RhoTech)
      ... situations ... I guess when you get right down to it, there aren t any overriding reasons to have it since the external iconv command can basically do
      Message 2 of 5 , Dec 28, 2000
        > You could also convert with the external iconv program. It's slower, but
        > should be sufficient when using it ocasionally. So, what are the
        situations
        > you really need an iconv() function inside Vim?

        I guess when you get right down to it, there aren't any overriding reasons
        to have it since the external 'iconv' command can basically do the same
        thing.

        It just seems like a waste to have all the iconv() functionality inside vim,
        and to force people to go through an external interface to get to it.

        In any case, the charset mapping remains a problem for people who want to do
        an external iconv!

        Ron
      Your message has been successfully submitted and would be delivered to recipients shortly.