On Saturday, July 12, 2014 6:09:11 PM UTC-5, Linda A. Walsh wrote: > Have two request, actually, > > > > 1) first is to honor the 'eol' setting in text files just as > > in binary > >
I like this idea. Setting 'binary' has a bunch of nasty side effects (like not working with fileformat not equal to unix, ignoring file encodings, etc.). > > 2) is to not make changes to a user's file unless they > > ask them to be made (i.e. 'eol' would be "true" by > > default -- don't modify end-of-file). With the > > option to modify EOF by adding an 'eol' being > > the optional behavior? > > > > thanks... while 2 might generate some controversy, is there > > a reason why "1" would be problem? > Currently 'eol' gets set according to whether or not the file currently has a newline on the last line, so that Vim can remember whether or not to add it for binary files. If you're editing with 'binary' set then you need to manually override the 'eol' option to change the file. Unfortunately I can't think of a good way to default to adding the EOL on text files like Vim does now if this option were made to work without binary mode. But does this matter? Most users won't even know the difference. Those that know the difference and care about it should be able to add an autocmd to override 'eol' on every file not binary. It is easy to override to always add EOL. It is difficult to detect whether EOL was there in the first place and force Vim to keep it the same: http://vim.wikia.com/wiki/Preserve_missing_end-of-line_at_end_of_text_files One thing we can't do is make 'eol' default to one value or another always; it needs to remember the state of the file as read, similar to how 'bomb' works, so that Vim can write the file back the way it was read in. I'm actually confused why it only works that way now when 'binary' is set. I DO think that 'eol' should be set by default on new buffers so that Vim defaults to writing "good" files. But I agree in general that there should be an easy way to make sure Vim doesn't make changes to files I don't intend to make. It can cause frustration during peer reviews on files with a strict change control process to see lines marked as having changed with no actual changes. -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
