atom feed18 messages in com.googlegroups.vim_useRe: Binary files, noeol, and other su...
FromSent OnAttachments
AaronOct 24, 2006 8:02 am 
A.J.MechelynckOct 24, 2006 8:58 am 
AaronOct 24, 2006 9:07 am 
Yakov LernerOct 24, 2006 9:26 am 
Bram MoolenaarOct 24, 2006 9:28 am 
A.J.MechelynckOct 24, 2006 9:36 am 
AaronOct 24, 2006 9:38 am 
AaronOct 24, 2006 9:51 am 
Gary JohnsonOct 24, 2006 10:09 am 
A.J.MechelynckOct 24, 2006 10:10 am 
Marvin RenichOct 24, 2006 10:11 am 
AaronOct 24, 2006 10:14 am 
AaronOct 24, 2006 10:26 am 
A.J.MechelynckOct 24, 2006 10:35 am 
Matthew WinnOct 25, 2006 3:24 am 
Yakov LernerOct 25, 2006 5:18 am 
VigilOct 26, 2006 2:43 am 
VigilOct 26, 2006 2:49 am 
Subject:Re: Binary files, noeol, and other such things.
From:A.J.Mechelynck (
Date:Oct 24, 2006 9:36:54 am

Aaron wrote:

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.

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

:autocmd BufWritePre *.xyz setlocal binary :autocmd BufWritePost *.xyz setlocal nobinary

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.