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

Re: Using GVIM with two keyboard layouts?

Expand Messages
  • Glenn Maynard
    ... It should work as long as encoding is set to either cp866 or an encoding that is a superset of cp866, such as UTF-8. If encoding=cp1252 and you try to
    Message 1 of 8 , Mar 14, 2003
    • 0 Attachment
      On Fri, Mar 14, 2003 at 10:51:27PM +0300, Valery Kondakoff wrote:
      > Excuse, pls, my bad English. I don't wanted to say, that using
      > 'encoding=utf-8' is a drawback. I was trying to say, that it is very
      > bad, that encoding conversion (like ':e ++enc=cp866') works properly
      > _only_ when you set 'encoding' to 'utf-8'.

      It should work as long as "encoding" is set to either cp866 or an
      encoding that is a superset of cp866, such as UTF-8.

      If "encoding=cp1252" and you try to do ":e ++enc=cp866", the conversion
      can only fail; the conversion is impossible.

      > For example, I'm using two encodings on my system - cp1251 (defaul
      > one) and cp866 (so I don't really need to use 'utf-8'). But when I set
      > 'encoding=cp1251' encoding conversion fails _very_ often (this is a
      > known issue, AFAIK).

      cp1252 is not a superset of cp866--it's impossible to convert cp866 to
      cp1252. (I don't know if the reverse is true; I doubt it.)

      That is, fileencoding=cp866 and encoding=cp1252 failing to convert is not
      a bug; the conversion is (generally) impossible.

      It's possible to change "encoding" to the encoding of the file you're
      currently working on and not convert at all, but this has all sorts of
      other problems (you're not supposed to do this).

      > And if I set 'encoding=utf-8', I can't use
      > clipboard copying and langmaps (see my initial message).

      Clipboard copying is being worked on. I can't help with langmaps, though.

      --
      Glenn Maynard
    • Valery Kondakoff
      Hello, Glenn! 14 ìàðòà 2003 ã., you wrote to me: ... GM If encoding=cp1252 and you try to do :e ++enc=cp866 , the conversion GM can only fail; the
      Message 2 of 8 , Mar 14, 2003
      • 0 Attachment
        Hello, Glenn!

        14 марта 2003 г., you wrote to me:

        GM> On Fri, Mar 14, 2003 at 10:51:27PM +0300, Valery Kondakoff wrote:
        >> Excuse, pls, my bad English. I don't wanted to say, that using
        >> 'encoding=utf-8' is a drawback. I was trying to say, that it is very
        >> bad, that encoding conversion (like ':e ++enc=cp866') works properly
        >> _only_ when you set 'encoding' to 'utf-8'.
        >> For example, I'm using two encodings on my system - cp1251 (defaul
        >> one) and cp866 (so I don't really need to use 'utf-8'). But when I set
        >> 'encoding=cp1251' encoding conversion fails _very_ often (this is a
        >> known issue, AFAIK).

        GM> If "encoding=cp1252" and you try to do ":e ++enc=cp866", the conversion
        GM> can only fail; the conversion is impossible.
        GM> cp1252 is not a superset of cp866--it's impossible to convert cp866 to
        GM> cp1252. (I don't know if the reverse is true; I doubt it.)
        GM> That is, fileencoding=cp866 and encoding=cp1252 failing to convert is not
        GM> a bug; the conversion is (generally) impossible.

        Yes, it seems I got the idea. This is not a bug, this is just a matter
        of implemetation.

        However conversion _is_ possible. For example, when I set my _vimrc
        like this:

        let &termencoding = &encoding
        set encoding=cp1251
        set fileencodings=cp1251,cp866,koi8-r
        set guifont=courier_new:h11
        set langmap=ЙQ,ЦW,... (etc)

        I still can open files in cp866 and koi8 encoding, and they will be
        converted to cp1251 and opened with label 'Converted'. The problem is,
        that not _all_ of the files are converted succesfully. I see this
        right now with my own eyes: 'encoding' is set to 'cp1251', the file is
        in 'cp866'. When I'm opening it in GVIM it is displayed correctly, it
        reads 'Converted' in status line and if I execute ':set fileencoding?'
        I'll receive 'fileencoding=cp866'.

        Approximately 60% of files are converted succsessfully. So - I'm just
        wondering: if conversion is possible for the most of the files, why it
        is impossible for ither 40%? :)

        GM> Clipboard copying is being worked on. I can't help with langmaps,
        GM> though.

        Yes, thank you!

        --
        Best regards,
        Valery Kondakoff
        http://www.nbk.orc.ru (Ne Bey Kopytom)
        http://www.nbk.orc.ru/mtb (MTB riding in Moscow)

        PGP key: mailto:pgp-public-keys@...?subject=GET%20strauss@...
      • Glenn Maynard
        *Please* make your mailer stop putting my name on the list address, it s confusing and annoying. ... It can convert when the file only contains characters in
        Message 3 of 8 , Mar 14, 2003
        • 0 Attachment
          *Please* make your mailer stop putting my name on the list address, it's
          confusing and annoying.

          On Sat, Mar 15, 2003 at 12:07:48AM +0300, Valery Kondakoff wrote:
          > I still can open files in cp866 and koi8 encoding, and they will be
          > converted to cp1251 and opened with label 'Converted'. The problem is,
          > that not _all_ of the files are converted succesfully. I see this
          > right now with my own eyes: 'encoding' is set to 'cp1251', the file is
          > in 'cp866'. When I'm opening it in GVIM it is displayed correctly, it
          > reads 'Converted' in status line and if I execute ':set fileencoding?'
          > I'll receive 'fileencoding=cp866'.

          > Approximately 60% of files are converted succsessfully. So - I'm just
          > wondering: if conversion is possible for the most of the files, why it
          > is impossible for ither 40%? :)

          It can convert when the file only contains characters in the destination
          encoding. For example, if it only contains ASCII, it'll convert to any
          codepage. Many encodings share a few accented Latin characters, so
          they'll often convert, too. If it contains Cyrillic characters, it'll
          almost never convert, since CP1252 simply doesn't have those characters.

          --
          Glenn Maynard
        • Valery Kondakoff
          15 ìàðòà 2003 ã., you wrote to me: GM *Please* make your mailer stop putting my name on the list address, it s GM confusing and annoying. OK. ... GM
          Message 4 of 8 , Mar 14, 2003
          • 0 Attachment
            15 марта 2003 г., you wrote to me:

            GM> *Please* make your mailer stop putting my name on the list address, it's
            GM> confusing and annoying.

            OK.

            >> I still can open files in cp866 and koi8 encoding, and they will be
            >> converted to cp1251 and opened with label 'Converted'. The problem is,
            >> that not _all_ of the files are converted succesfully. I see this
            >> right now with my own eyes: 'encoding' is set to 'cp1251', the file is
            >> in 'cp866'. When I'm opening it in GVIM it is displayed correctly, it
            >> reads 'Converted' in status line and if I execute ':set fileencoding?'
            >> I'll receive 'fileencoding=cp866'.

            >> Approximately 60% of files are converted succsessfully. So - I'm just
            >> wondering: if conversion is possible for the most of the files, why it
            >> is impossible for ither 40%? :)

            GM> It can convert when the file only contains characters in the destination
            GM> encoding. For example, if it only contains ASCII, it'll convert to any
            GM> codepage. Many encodings share a few accented Latin characters, so
            GM> they'll often convert, too. If it contains Cyrillic characters, it'll
            GM> almost never convert, since CP1252 simply doesn't have those characters.

            Yes, that is true. Since I was talking about three Russian encodings,
            that (in general) have similar characters, it's possible to convert
            between them. Just take a look at screenshot:
            http://www.nbk.orc.ru/temp/866.png (~25k).

            And if this file has a character, that is not available in
            cp1251 encoding, the conversion will fail. Thank you for explanation.

            Why there was not implemented something like 'force' encoding
            conversion, that will convert all characters, that can be converted
            leaving all unidentified characters at their own? (It's sad, that the
            entire file cannnot be converted from cp866 to cp1251 becouse of _one_
            non-alphabet symbol that is missed in cp1251!)

            --
            Best regards,
            Valery Kondakoff
            http://www.nbk.orc.ru (Ne Bey Kopytom)
            http://www.nbk.orc.ru/mtb (MTB riding in Moscow)

            PGP key: mailto:pgp-public-keys@...?subject=GET%20strauss@...
          • Glenn Maynard
            ... Oh. You should have corrected CP1252 , then (which is US/English.) That in mind, the explanation I gave may or may not be relevent--I don t know how the
            Message 5 of 8 , Mar 14, 2003
            • 0 Attachment
              On Sat, Mar 15, 2003 at 01:56:09AM +0300, Valery Kondakoff wrote:
              > GM> they'll often convert, too. If it contains Cyrillic characters, it'll
              > GM> almost never convert, since CP1252 simply doesn't have those characters.
              >
              > Yes, that is true. Since I was talking about three Russian encodings,
              > that (in general) have similar characters, it's possible to convert
              > between them. Just take a look at screenshot:

              Oh. You should have corrected "CP1252", then (which is US/English.)

              That in mind, the explanation I gave may or may not be relevent--I
              don't know how the various Russian encodings overlap.

              --
              Glenn Maynard
            Your message has been successfully submitted and would be delivered to recipients shortly.