Let's assume we have two text documents:
hi
" as text.hi
" as text.When we open these two files in gedit, vi, or vim, the two files are visually identical in every way.
However, when we run xxd
on the files, we get the following:
6869
6869 0a
Aha! There's an invisible newline. In vim, if we were paying close enough attention to the status bar and happen to understand what [noeol]
means, then we might pick up on this, but in gedit, the two files open exactly the same!
In a small survey, when I asked people to distinguish between the two files using only gedit or vim, they failed 100% of the time. When I asked them to accomplish the same task using leafpad or emacs, they succeeded 100% of the time.
I understand that vi and gedit want to add a newline to every file they create (and I acknowledge that there are probably advantages to this). What I don't understand is why gedit and vim think visually hiding this newline from their users is beneficial? Especially when this kind of behavior is potentially extremely destructive...
(Take for instance the two C-programmers who see the contents of these two files the same in their vi/gedit text editor, and then assuming what they see is what they get, go on to write the contents into the array
char greeting[2]
. The first programmer writing the first file - although a bit sloppy with his code - goes on to fame and fortune, but the second programmer writing the second file, dies in miserable poverty, confused and bewildered by this invisible (and preventable) stack overflow.)
So pray tell, what are the advantages of having text editors like vim and gedit add invisible newlines at the end of each document they create, and then proceed to hide those newlines from the user, so that the true contents of these files are only visibly detectable using other text editors?
Vim doesn't show latest newline in the buffer but actually vim always place EOL at the end of the file when you write it, because it standard for text files in Unix systems. You can find more information about this here. In short you don't have to worry about the absence a new lines at the end of the file in vim.
That's why Vim always adds a newline by default (because, according to POSIX, it should always be there). It is not the only editor doing that. Gedit, the default text editor in GNOME, does the same exact thing.
Windows uses a combination of two characters: 0xD 0xA. 0xD is the carriage return character. ^M happens to be the way vim displays 0xD (0x0D = 13, M is the 13th letter in the English alphabet). You can remove all the ^M characters by running the following: :%s/^M//g.
That you perceive the last line as "visually hidden" stems from the opposite viewpoints.
Many people (especially with a Unix background) argue that text files should always end with a newline (e.g. see Why should text files end with a newline?), and that any text editor that allows to create files without it is fundamentally broken. From that perspective, that there is no additional empty line in Vim is only consistent with this world view. The file appears in the editor as it would when it is cat
ed into the terminal.
From Vim's point of view, a file with a missing newline is heretical and defective; that's why it is indicated with the [noeol]
message on load (and it is quite hard to edit the file while keeping the missing newline; though I've written the PreserveNoEOL plugin to aid with that).
I believe this is a convention, that is carried over from vi. One advantage of doing so, is that when concatenating files, you can still distinguish where each file ended.
Some more context is provided in this thread on the vim_use mailinglist
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