Christian: > The copy is still in the buffer. It is valid. The problem is, that > writing failed because converting to your desired fileencoding failed. > > The problem is probably, that Vim opened the file for writing, truncated > it and when writing noticed the error. But at this time, the old > contents are already gone.
This explains the current way Vim handles the process. It does not have to be this way. This is what I mean by bad design. Loss of data should only happen in an unforeseen situation (a crash, etc). If you are truncating a file, especially prior to a conversion that can fail, you should take extra precautions. > Besides, big red warning messages should always be read, because they > don't usually happen. This is the "Soviet" style of user interface design: it dictates *how* people should use a product, and ignores the real-life scenarios. (Much like the opening line of your message - "Please don't top poste and please wrap to 75 columns.") If I *really* care about customer feedback, I don't care how the customer sends me feedback / it can be top-posted, bottom-posted, sideways. What is important is that I am getting feedback about the worst thing that can happen w/ my product. I am done w/ this issue, thank you all for your responses. -- 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
