A.J.Mechelynck wrote: > 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. > >
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. 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! -- Aaron "The Dude abides."
