I have been able to reproduce it. I have "vim_error.py" file with followoing contents:
# vim: set fileencoding=cp857: ı The file has three lines, the modeline, the second line, which is blank, and the third line, where there is a dotless lowercase i from the 857 code page. File loads fine in Vim. Then I change 'fileencoding' in the modeline to 'encoding' (i.e. just delete the four characters 'file' from 'fileencoding'), everything else remaining the same. Result: "vim_error.py" (in yellow) "vim_error.py" E513: write error, conversion failed (make 'fenc' empty to override) WARNING: Original file may be lost or damaged don't quit the editor until the file is successfully written! (In orange) Press ENTER or type command to continue (in green) What I meant by bad design decision: When the conversion fails, why not simply restore the previous buffer? The unacceptable behaviour is that even if I do a "q!", I still lose the file. Thanks - Todd On Sunday, May 13, 2012 2:20:10 PM UTC+3, Christian Brabandt wrote: > Hi Toddintr! > > On So, 13 Mai 2012, Toddintr wrote: > > > For the first time ever since I started using Vim, I lost a file. I had a > > modeline that specified an "encoding" setting for a Python script. Vim > > complained when opening the file. I googled for a solution, decided to try > > fileencoding instead of encoding. When saving the file, I saw some > > error/warning messages, but went ahead with a ZZ or w! (don't quiet > > remember). Result: File length of zero. (Had backups disabled.) > > > > My point: I *LOVE* Vim. However, this sort of design decision is > > unacceptable. It seems to be a design decision because it was not a bug or > > a crash. > > > > My two-cents' worth. > > Can you reproduce it? > > regards, > Christian > -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
