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.

Thanks Tony, that's along the lines of what I expected to hear back
from everyone. Perhaps my solution is to edit the file normally and
then set binary just before writing it to preserve its broken state.

yes, that should work if you're dead set on writing a file without a
final EOL. You might even automate it further by defining
autocommands: let's say that particular filetype is identified by
extension .xyz -- then you can define

If anyone is curious, the reason this came up is because ColdFusion
custom tags will print that trailing newline as a space even when you
tell it to suppress white space. The only way to avoid it is to save
the custom tag file without the final newline (as a broken file).

In this case, two wrongs do equal a right...

Sorry for the long lines and top-posting in my earlier
correspondence!

No problem.

Best regards,
Tony.

You beat me to it, I was halfway through reading the autocommands help
entry when this came through. Thanks, Yakov, for suggesting this.

Here's a thought, though. There is nothing in the file type or filename
that will indicate that it is a custom tag, but the file will *always*
live in /some/path/custom_tags/myfile.cfm. That's where the CF server
will look for custom tags so they have to be there by design.