I am assuming that prior to attempting to write the file and failing, Vim had a valid copy in the buffer. It should restore that copy.
Otherwise, if it is going to attempt something that is not reversible, it should never attempt it. It is one of the fundamentals of software systems design as I know it. Losing a file is the worst thing that an editor can do. On Sunday, May 13, 2012 3:31:38 PM UTC+3, Christian Brabandt wrote: > Hi Toddintr! > > On So, 13 Mai 2012, Toddintr wrote: > > > 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. > > You get a warning, that writing failed and the file may possibly be > corrupt. Vim even tells you, what you should do to write without > converting the content. What else should Vim do? > > I don't understand, what Vim should possibly restore? > > 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
