Aaron wrote:
Please, oh Vim gurus, explain this binary/noeol situation. It seems to
me that if I open a text file in e.g. metapad or Edit Plus or any of
these other very simple Windows-based text editors, I am able to delete
the "final line break," which appears on screen as though there is a
zero-length line right after the last line of text. I press backspace on
that empty line and it is gone; so is the EOL.
In order to achieve this in Vim, I must perform strange acrobatics
including turning on "binary," which clobbers my textwidth, wrapmargin,
expandtab, and modeline options, and forces unix-like line separators.
My only guess is that Vim follows certain established rules for the
formatting of proper text files, but I have run across situations where
I need to edit text files (AS text files) that have no final EOL, and it
pains me that Vim makes this harder than such functionally limited
editors as Edit Plus.
Is there some Better Way?
In text, each line is supposed to end in an end-of-line. This avoids, for
instance, that concatenating two text files would make the last line of the
one run into the first line of the other. Whenever Vim writes a text file, it
makes sure that the last character or character pair is the end-of-line marker
corresponding to the file's 'filetype'. This is intentional.
In binary files (such as programs), there are no true "lines" to speak of, and
the length of the file must be preserved. Therefore Vim checks at load whether
the file ends in and end-of-line, saves it in the boolean buffer-local option
'eol', and uses that when writing the file. Alternately, you may filter binary
files through the xxd utility (distributed with Vim), and edit them in hex.
If other editors are broken in the sense that they forget to write the last
line's end-of-line marker, that's no fault of Vim's. And they _are_ broken: I
don't remember off the top of my head where the corresponding regulation is to
be found, but the matter has been discussed time and time again in these
mailing lists; I guess searching the list archive might give you something to
chew on.
Best regards,
Tony.
