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

Re: .swp file left behind on Windows

Expand Messages
  • Tony Mechelynck
    ... not on the modeline but as an ex-command. You need a Vim version with +multi_byte compiled-in and your encoding MUST already be set (preferably somewhere
    Message 1 of 10 , Dec 9, 2008
    • 0 Attachment
      On 10/12/08 01:46, Mansing wrote:
      > I tried changing "enc=" to "fenc=" in my mode line:
      > <!-- vim: set fo+=mM gfn=MingLiU\:h12 fenc=utf-8: -->
      > but my Chinese text doesn't show up correctly (as if this option were
      > omitted). I tried (after reading help 45.3 on ":edit ++enc=...") also
      > "++enc=" and "\+\+enc=", but Vim says this is not a known option (for
      > the mode line). Seems "enc=" is the only way that I can use to
      > (automatically) tell Vim about my file encoding.

      :edit ++enc=utf-8 filename.ext

      not on the modeline but as an ex-command. You need a Vim version with
      +multi_byte compiled-in and your 'encoding' MUST already be set
      (preferably somewhere near the top of your vimrc) to utf-8.

      If you have 'enc' set to utf-8 and 'fencs' starting with ucs-bom,utf-8
      (which is the default once you set 'enc' to utf-8), UTF-8 files ought to
      be correctly recognized without the need for anything special on either
      a modeline or the ":edit" ex-command.

      You can NEVER edit correctly a file which contains characters which your
      current 'encoding' setting cannot represent. For instance, with
      'encoding' set to Latin1 you cannot edit Chinese text because there are
      no Chginese glyphs in Latin1.

      > Note that I am not complaining any problem: I am happy with "enc=" in my
      > mode line as it works well with all context encodings I happened to use
      > --Big5, GB2312, utf-8 etc. I am just perplexed to hear that this is the
      > wrong way?
      > mt 081210

      'ecoding' affects the representation of data for ALL files in Vim
      memory. If 'encoding' was previously set to GBK, and you have a GBK file
      in another split-window, or even in a hidden buffer, opening a file
      whose modeline sets 'encoding' to UTF-8 will make Vim regard ALL text in
      ALL files as UTF-8 text, but the internal data in buffers already in
      memory will NOT be changed, so the other file will still contain GBK
      data, which Vim will now try to interpret as UTF-8 data, with
      catastrophic results (you'll get a lot of "invalid" UTF-8 characters,
      and probably none of the Chinese text in the GBK file will be recognizable).

      OTOH, if 'encoding' is set to UTF-8, typing ":e ++enc=gbk gbkfile.txt"
      will correctly edit the file gbkfile.txt if it uses GBK charset. Vim
      (with +multi_byte and +iconv compiled-in) will be happy to convert the
      file's data, GBK => UTF-8 when reading and UTF-8 => GBK when writing --
      provided, of course, that you don't insert any hanzi which has no GBK

      The only time when it is "safe" to change 'encoding' is when there are
      no nonempty buffers loaded into Vim. Your vimrc (which is sourced before
      actually loading any buffers) is one such "safe place". I recommend
      (whenever you run a Vim version with +multi_byte compiled-in) to set
      'encoding' to UTF-8 in your vimrc (after saving the previous 'encoding'
      value in 'termencoding' if the latter was empty), and never to change
      'encoding' later on.

      Best regards,
      The new Congressmen say they're going to turn the government around. I
      hope I don't get run over again.

      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.