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

Problem reloading a UTF-8 file

Expand Messages
  • Steve Gardner
    Hello, GVim seems to have a problem when reloading a UTF-8 text file after it has been changed by another application. The problem occurs with GVim versions
    Message 1 of 3 , Jul 15 12:22 PM
    • 0 Attachment
      Hello,

      GVim seems to have a problem when reloading a UTF-8 text file after it
      has been changed by another application. The problem occurs with GVim
      versions 7.1 and 7.2 beta on Windows XP. The steps to reproduce the
      problem on Windows are:
      1) Create a UTF-8 text file, starting with byte order mark EF-BB-BF.
      2) Open the file in GVim.
      2) While the file is open in GVim, make a change to the same file in
      another editor (e.g. use Notepad to append a character).
      3) Switch back to GVim. The warning "W11: Warning: File "\file.txt"
      has changed since editing started. See ":help W11" for more info." appears.
      4) Click "Load File" in the warning dialog box. The message
      "[CONVERSION ERROR in line 1]" appears at the bottom and an inverted
      question mark character appears at the start of the text.

      If you then save the file from GVim, the byte order mark changes from
      EF-BB-BF to C2-BF , which appears as spurious characters in GVim or
      other editors.

      I hope this is useful.

      Best regards

      Steve Gardner


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_multibyte" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tony Mechelynck
      ... - With another instance of gvim (in noswapfile mode) the BOM is not changed; reload clears the bomb option and starts a first line starting with
      Message 2 of 3 , Jul 15 1:09 PM
      • 0 Attachment
        On 15/07/08 21:22, Steve Gardner wrote:
        > Hello,
        >
        > GVim seems to have a problem when reloading a UTF-8 text file after it
        > has been changed by another application. The problem occurs with GVim
        > versions 7.1 and 7.2 beta on Windows XP. The steps to reproduce the
        > problem on Windows are:
        > 1) Create a UTF-8 text file, starting with byte order mark EF-BB-BF.
        > 2) Open the file in GVim.
        > 2) While the file is open in GVim, make a change to the same file in
        > another editor (e.g. use Notepad to append a character).
        > 3) Switch back to GVim. The warning "W11: Warning: File "\file.txt"
        > has changed since editing started. See ":help W11" for more info." appears.
        > 4) Click "Load File" in the warning dialog box. The message
        > "[CONVERSION ERROR in line 1]" appears at the bottom and an inverted
        > question mark character appears at the start of the text.
        >
        > If you then save the file from GVim, the byte order mark changes from
        > EF-BB-BF to C2-BF , which appears as spurious characters in GVim or
        > other editors.
        >
        > I hope this is useful.
        >
        > Best regards
        >
        > Steve Gardner

        - With another instance of gvim (in 'noswapfile' mode) the BOM is not
        changed; reload clears the 'bomb' option and starts a first line
        starting with <feff> (an explicit UTF-8 BOM); then ":e" sets 'bomb'
        again and the <feff> header disappears from the display.

        - With kedit the BOM is removed (by kedit), otherwise no error.

        Try the following:

        1. Create (with gvim) a UTF-8 file with BOM, then close the file.
        2. Edit the file in Netscape while gvim is not running, then close Netscape.
        3. Open the file in gvim.
        4.

        :setl fenc? bomb?

        What are the answers at step 4? Has by any chance the 'fileencoding'
        been changed?


        Best regards,
        Tony.
        --
        Power, n:
        The only narcotic regulated by the SEC instead of the FDA.

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_multibyte" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Steve Gardner
        ... Oh dear. At some point I must learn how to count to three. I shall rename the Notepad step Step 2a . ... I tried this on Windows with GVim 7.2b and on
        Message 3 of 3 , Jul 16 2:53 AM
        • 0 Attachment
          Tony Mechelynck wrote:
          > On 15/07/08 21:22, Steve Gardner wrote:
          >
          >> Hello,
          >>
          >> GVim seems to have a problem when reloading a UTF-8 text file after it
          >> has been changed by another application. The problem occurs with GVim
          >> versions 7.1 and 7.2 beta on Windows XP. The steps to reproduce the
          >> problem on Windows are:
          >> 1) Create a UTF-8 text file, starting with byte order mark EF-BB-BF.
          >> 2) Open the file in GVim.
          >> 2) While the file is open in GVim, make a change to the same file in
          >> another editor (e.g. use Notepad to append a character).
          >>
          Oh dear. At some point I must learn how to count to three.
          I shall rename the Notepad step "Step 2a".
          >> 3) Switch back to GVim. The warning "W11: Warning: File "\file.txt"
          >> has changed since editing started. See ":help W11" for more info." appears.
          >> 4) Click "Load File" in the warning dialog box. The message
          >> "[CONVERSION ERROR in line 1]" appears at the bottom and an inverted
          >> question mark character appears at the start of the text.
          >>
          >> If you then save the file from GVim, the byte order mark changes from
          >> EF-BB-BF to C2-BF , which appears as spurious characters in GVim or
          >> other editors.
          >>
          >> I hope this is useful.
          >>
          >> Best regards
          >>
          >> Steve Gardner
          >>
          >
          > - With another instance of gvim (in 'noswapfile' mode) the BOM is not
          > changed; reload clears the 'bomb' option and starts a first line
          > starting with <feff> (an explicit UTF-8 BOM); then ":e" sets 'bomb'
          > again and the <feff> header disappears from the display.
          >
          I tried this on Windows with GVim 7.2b and on Linux with GVim 7.1. On
          Linux, it did what you described, but on Windows it did not: I got the
          same problem as I reported.
          > - With kedit the BOM is removed (by kedit), otherwise no error.
          >
          > Try the following:
          >
          > 1. Create (with gvim) a UTF-8 file with BOM, then close the file.
          > 2. Edit the file in Netscape while gvim is not running, then close Netscape.
          > 3. Open the file in gvim.
          > 4.
          >
          > :setl fenc? bomb?
          >
          > What are the answers at step 4? Has by any chance the 'fileencoding'
          > been changed?
          >
          >
          > Best regards,
          > Tony.
          >

          I have followed your steps 1-4 (but with Notepad instead of Netscape)
          and the reply from ":setl fenc? bomb?" was:
          fileencoding=utf-8
          bomb
          Notepad didn't change the BOM (I have also checked this with a binary
          file viewer).
          I have also reproduced the original problem replacing my step "2a" with
          a DOS copy command, overwriting the file with another carrying the same
          BOM (but with different text).

          I cannot make the problem happen on Linux though.

          Best regards
          Steve

          --~--~---------~--~----~------------~-------~--~----~
          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.