This question is a follow up to the Work Around I use for "saving files in vim without having the newline at end of file forcibly added" annoyance.
Basically I can't use set noeol
in my .vimrc
because it does Nothing!
It does what it's supposed to do though if I edit the file in binary mode. (vim -b file
instead of vim file
)
Why is that?
Anyway to have a simple preference in .vimrc
to NOT add newlines at every single file I edit?
Also, what kind of issues will I encounter if I start to edit every file in binary mode? So far I haven't seen any difference.
Its 'NO EOL' - no end of line indicator. Very helpful if you end up opening a very large file (>1GB). Vim tries to pull all that in 1 line. This indicator helps me quickly close the file before it screws up my OS.
Vim can sort of do the job, but it's obviously not designed for it, and if you ever write without :set binary Vim might destroy your binary files! The only thing that works is :r ! xxd <file> (or $ xxd <file> | vim - ) to read, and :w ! xxd -r > <file> to write, but this is not ideal.
In vim command mode, type: :help read-messages. You can see: [converted] conversion from 'fileencoding' to 'encoding' done. In general, it means that vim detected the file did not match the charset given by your locale and made a conversion.
What Vim "adds" to the end of the last line in your file is the "newline" character, which should not to be confused with a "new line".
The "newline" character or more accurately "end of line" character (<EOL>
) means "whatever comes after this point must be considered to be on another line". With this interpretation — <EOL>
is a line terminator — the last line of the file is effectively the last one with an <EOL>
.
The problem is that most editors and IDEs have a different interpretation — <EOL>
is a line separator — and, logically, default to not add an <EOL>
at the end of the last line of a new file and, when they encounter an <EOL>
, add a superfluous "new line" after the real last line.
In short, Vim doesn't add a "new line": other editors interpret (wrongly) its "newline" as a "new line".
But you can get around that issue by doing the following: before you write your file, do :set binary noeol
if you want it to stay "<EOL>
-free".
However, :h 'binary'
has a lot to say about the perils of :set binary
so I'd say that turning it "on" all the time sounds like a bad idea.
To illustrate the different behaviors, this is what happens when you try to concatenate two files with <EOL>
:
$ cat file1 $ cat file2 $ cat file1 file2 lorem ipsum Le tramway jaune lorem ipsum dolor sit avance lentement dolor sit amet dans le amet Le tramway jaune avance lentement dans le
and this is what happens when you try to concatenate two files without <EOL>
:
$ cat file1 $ cat file2 $ cat file1 file2 lorem ipsum Le tramway jaune lorem ipsum dolor sit avance lentement dolor sit amet dans le ametLe tramway jaune avance lentement dans le
The first behavior is somehow the expected behavior and the reason why Vim and many (if not most) UNIX-y programs default to the terminator interpretation and to adding an <EOL>
character at the end of the last line.
The picture below shows a simple file with <EOL>
created with nano
(it would be the same with Vim) and opened in Eclipse, TextMate, Sublime Text, Vim, Xcode and TextEdit.
(edit) There is no line 4 in this file and the only editor of the bunch that displays the file correctly is Vim. A line number column's only purpose is to provide information on the buffer. Showing 4 lines where there are only 3 is a gross mistake. (endedit)
This picture shows another simple file without <EOL>
created with Sublime Text and opened in the same editors/IDEs.
from version 7.4.785 vim has fixendofline
setting. You can avoid binary
(which has some side effects) and simply set
set noendofline set nofixendofline
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With