How to stop vim from adding a newline at end of file? - vim

So I work in a PHP shop, and we all use different editors, and we all have to work on Windows. I use vim, and everyone in the shop keeps complaining that whenever I edit a file there is a newline at the bottom. I've searched around and found that this is a documented behavior of vi & vim... but I was wondering if there was some way to disable this feature. (It would be best if I could disable it for specific file extensions).
If anyone knows about this, that would be great!

And for vim 7.4+ you can use (preferably on your .vimrc) (thanks to 罗泽轩 for that last bit of news!):
:set nofixendofline
Now regarding older versions of vim.
Even if the file was already saved with new lines at the end:
vim -b file
and once in vim:
:set noeol
:wq
done.
alternatively you can open files in vim with :e ++bin file
Yet another alternative:
:set binary
:set noeol
:wq
see more details at Why do I need vim in binary mode for 'noeol' to work?

Add the following command to your .vimrc to turn of the end-of-line option:
autocmd FileType php setlocal noeol binary fileformat=dos
However, PHP itself will ignore that last end-of-line - it shouldn't be an issue. I am almost certain that in your case there is something else which is adding the last newline character, or possibly there is a mixup with windows/unix line ending types (\n or \r\n, etc).
Update:
An alternative solution might be to just add this line to your .vimrc:
set fileformats+=dos

There is another way to approach this if you are using Git for source control. Inspired by an answer here, I wrote my own filter for use in a gitattributes file.
To install this filter, save it as noeol_filter somewhere in your $PATH, make it executable, and run the following commands:
git config --global filter.noeol.clean noeol_filter
git config --global filter.noeol.smudge cat
To start using the filter only for yourself, put the following line in your $GIT_DIR/info/attributes:
*.php filter=noeol
This will make sure you do not commit any newline at eof in a .php file, no matter what Vim does.
And now, the script itself:
#!/usr/bin/python
# a filter that strips newline from last line of its stdin
# if the last line is empty, leave it as-is, to make the operation idempotent
# inspired by: https://stackoverflow.com/questions/1654021/how-can-i-delete-a-newline-if-it-is-the-last-character-in-a-file/1663283#1663283
import sys
if __name__ == '__main__':
try:
pline = sys.stdin.next()
except StopIteration:
# no input, nothing to do
sys.exit(0)
# spit out all but the last line
for line in sys.stdin:
sys.stdout.write(pline)
pline = line
# strip newline from last line before spitting it out
if len(pline) > 2 and pline.endswith("\r\n"):
sys.stdout.write(pline[:-2])
elif len(pline) > 1 and pline.endswith("\n"):
sys.stdout.write(pline[:-1])
else:
sys.stdout.write(pline)

I have not tried this option, but the following information is given in the vim help system (i.e. help eol):
'endofline' 'eol' boolean (default on)
local to buffer
{not in Vi}
When writing a file and this option is off and the 'binary' option
is on, no <EOL> will be written for the last line in the file. This
option is automatically set when starting to edit a new file, unless
the file does not have an <EOL> for the last line in the file, in
which case it is reset.
Normally you don't have to set or
reset this option. When 'binary' is
off the value is not used when writing
the file. When 'binary' is on it is
used to remember the presence of a
for the last line in the file,
so that when you write the file the
situation from the original file can
be kept. But you can change it if you
want to.
You may be interested in the answer to a previous question as well: "Why should files end with a newline".

I've added a tip on the Vim wiki for a similar (though different) problem:
http://vim.wikia.com/wiki/Do_not_auto-add_a_newline_at_EOF

OK, you being on Windows complicates things ;)
As the 'binary' option resets the 'fileformat' option (and writing with 'binary' set always writes with unix line endings), let's take out the big hammer and do it externally!
How about defining an autocommand (:help autocommand) for the BufWritePost event? This autocommand is executed after every time you write a whole buffer. In this autocommand call a small external tool (php, perl or whatever script) that strips off the last newline of the just written file.
So this would look something like this and would go into your .vimrc file:
autocmd! "Remove all autocmds (for current group), see below"
autocmd BufWritePost *.php !your-script <afile>
Be sure to read the whole vim documentation about autocommands if this is your first time dealing with autocommands. There are some caveats, e.g. it's recommended to remove all autocmds in your .vimrc in case your .vimrc might get sourced multiple times.

I've implemented Blixtor's suggestions with Perl and Python post-processing, either running inside Vim (if it is compiled with such language support), or via an external Perl script. It's available as the PreserveNoEOL plugin on vim.org.

Starting with vim v7.4 you can use
:set nofixendofline
There is some information about that change here: http://ftp.vim.org/vim/patches/7.4/7.4.785 .

Maybe you could look at why they are complaining. If a php file has a newline after the ending ?>, php will output it as part of the page. This is not a problem unless you try to send headers after the file is included.
However, the ?> at the end of a php file is optional. No ending ?>, no problem with a newline at the end of the file.

Try to add in .vimrc
set binary

I think I've found a better solution than the accepted answer. The alternative solutions weren't working for me and I didn't want to have to work in binary mode all the time.
Fortunately this seems to get the job done and I haven't encountered any nasty side-effects yet: preserve missing end-of-line at end of text files. I just added the whole thing to my ~/.vimrc.

Would it be possible for you to use a special command for saving these files?
If you do :set binary, :w and :set nobinary the file will be written without newline if there was none to start with.
This sequence of commands could be put into a user defined command or a mapping, of course.

I found this vimscript plugin is helpful for this situation.
Plugin 'vim-scripts/PreserveNoEOL'
Or read more at github

Related

Vim(Gvim) - How do I install a script on Windows 7?

I want to install this closetag.vim script:
http://vim.sourceforge.net/scripts/script.php?script_id=13
It says
place this file in your standard vim scripts directory and source it
while editing the file you wish to close tags in.
And this is shown as an example:
:let g:closetag_html_style=1
:source ~/.vim/scripts/closetag.vim
1) What is my standard vim scripts directory on W7?
I have neither .vim nor scripts folder on my system. And if I have\am expected to create one (or ones) where should it (they) be placed? %ProgramFiles%\Vim\vim80 or %ProgramFiles%\Vim\vimfiles or maybe somewhere else?
1.1) Also, this might be a silly thing to ask about, but why do I keep seeing that tilde in path almost every time I read about Vim. Does it mean that Vim is used primarily by Mac/Linux people? Why is that?
2) What does it mean to source the script? Run a command like this let g:closetag_html_style=1 in command mode in Vim?
Btw what does style=1 mean here?
And if I want it to work by default for all html\xhtml\xml files, what do I do? Put this command to _vimrc file?
Thank you so much!
You could find the answers to all your questions just by reading the plugin description carefully. Unfortunately, it is both poorly written and factually incorrect.
What is my standard vim scripts directory on W7?
On Windows, you are supposed to put custom and third-party scripts in various places under:
C:\Users\username\vimfiles\
But that's not what the author means by "standard vim scripts directory". What he is referring to is this:
C:\Users\username\vimfiles\scripts\
which is not standard at all.
Also, this might be a silly thing to ask about, but why do I keep seeing that tilde in path almost every time I read about Vim. Does it mean that Vim is used primarily by Mac/Linux people? Why is that?
Yes, Vim is primarily used by UNIX-like systems users. Because of history.
What does it mean to source the script? Run a command like this let g:closetag_html_style=1 in command mode in Vim?
No. Read your question again.
Btw what does style=1 mean here?
Nothing.
But :let g:closetag_html_style=1 means "set the g:closetag_html_style option to true".
And if I want it to work by default for all html\xhtml\xml files, what do I do? Put this command to _vimrc file?
No. This is explained on the plugin's page:
For greater convenience, load this script in an autocommand:
:au Filetype html,xml,xsl source ~/.vim/scripts/closetag.vim
Which is wrong on many levels.
Here is what you actually have to do to use that script:
Save the closetag.vim script to the following location:
C:\Users\username\vimfiles\scripts\closetag.vim
Create vimfiles\ and/or vimfiles\scripts\ if they don't exist.
Add the lines below to C:\Users\username\_vimrc:
augroup closetag
autocmd!
autocmd Filetype html,xhtml,xml,xsl runtime scripts/closetag.vim
augroup END
let g:closetag_html_style = 1
Reference:
:help startup
:help :source
:help :runtime
:help :let
:help autocommand

Why can't I change vim syntax highlighting via local vimrc file?

I am trying to customize vim highlighting by placing additional instructions into local config $project/.lvimrc, which is managed by the https://github.com/embear/vim-localvimrc plugin.
Unfortunately, it seems that commands like
syntax match Operator "\<MYOP\>"
located in .lvimrc are ignored silently by vim. Typing the command in the command line works as expected. Other commands from .lvimrc also work. So what may stop vim from interpreting local highlighting correctly?
That was because https://github.com/embear/vim-localvimrc plugin launches local files in a sandbox by default. Syntax commands are not allowed in a sandbox (at least in my setup), so the exception was raised. For some reason, Vim handles such exceptions silently.
In my case, the following modifications formed a solution:
Disable sandboxes for localvimrc by adding let g:localvimrc_sandbox = 0 to master .vimrc file
Add set conceallevel=2 to the localvimrc
It could be a problem with the loading order, i.e., your .lvimrc is loaded, then the filetype syntax is loaded and overwrites the .lvimrc syntax commands. You could check that by including echom statements on both files.
Also notice that the local vimrc is not the standard way of customizing syntax highlight. From Vim FAQ 24.11:
You should not modify the syntax files supplied with Vim to add your
extensions. When you install the next version of Vim, you will lose your
changes. Instead you should create a file under the ~/.vim/after/syntax
directory with the same name as the original syntax file and add your
additions to this file.
For more information, read
|mysyntaxfile-add|
|'runtimepath'|

set complete+=k[file] not working for whole line completion?

I have ~/.bash_history that contains lines such as sudo apt-get install, aplay foo.wav, etc. I thought it would be convenient if I could use these lines for completing whole lines while writing shell scripts.
:h compl-whole-line says:
CTRL-X CTRL-L
Search backwards for a line that starts with the
same characters as those in the current line before
the cursor. Indent is ignored. The matching line is
inserted in front of the cursor.
** The 'complete' option is used to decide which buffers
are searched for a match. Both loaded and unloaded
buffers are used.**
Note the asterisks I inserted. :h 'complete' says:
k k{dict} scan the file {dict}. Several "k" flags can be given,
patterns are valid too. For example: >
:set cpt=k/usr/dict/*,k~/spanish
So I thought :set complete+=k~/.bash_history would do the job. It didn't.
Start vim with
$ vim -u NONE -N
then
:set complete+=k~/.bash_history
:set complete?
" complete=.,w,b,u,t,i,k~/.bash_history
, I enter to the insert mode (i), and when I type
su<C-x><C-l>
, vim says Whole line completion (^L^N^P) Pattern not found. The completion is working for words, so when I type
su<C-p>
sudo is suggested.
What am I missing? How can I use my history for whole line completion without :sp ~/.bash_history?
set complete+=k[file] has nothing to do with line completion: whatever file you give to it will only be used as a source by dictionary completion (<C-x><C-k>) and keyword completion (<C-n>/<C-p>).
:help i_ctrl-x_ctrl-l is clear: line completion only works with lines found in loaded and unloaded buffers. Since ~/.bash_history is not loaded as a buffer, line completion will obviously never use it as a source.
So yes, the only practical solution is to load that file.
:sp ~/.bash_history is not really optimal, though, because a) it takes too much room, both physically and in your buffer list, and b) it requires way too many keystrokes.
The "too much room" part of the problem is easily solved with a more suited command:
:badd ~/.bash_history
The "too many keystrokes" part of the problem could be solved with an autocommand that runs the command above each time you edit a shell script:
augroup shell
autocmd!
autocmd BufNewFile,BufRead *.sh badd ~/.bash_history
augroup END

How to edit a file in Vim with all lines ending in ^M except the last line ending in ^M^J

I have a bunch of files that I need to look at. All lines in these files end in ^M (\x0D) except the very last line that ends in ^M^J (\x0D\x0A).
Obviously, Vim determines the filetype to be DOS with the effect that the file's entire content is
displayed on one single line like so:
some text foo^Mmore text and^Ma few control-m^Ms and more and more
Since I don't want to change the files' content: is there a setting in Vim that allows to look at these
files with the new lines as I'd expect them to be?
If you do not mind having a line at the bottom containing a single ^J character, you can set fileformats (note the s at the end) to mac and reload the buffer:
:set fileformats=mac
:edit
Or equivalently you could start the editor as follows:
vim -R "+set fileformats=mac" "+edit" <filename>
The -R (readonly) option is there because you stated you do not want to change the files.
I did not find a way that does not involve reloading the buffer.
Try this:
:set fileformat=unix
Can't really verify it though, since I don't have that kind of files handy.

How to highlight Bash scripts in Vim?

My Vim editor auto highlights PHP files (vim file.php), HTML files (vim file.html) and so on.
But when I type: vim file and inside it write a Bash script, it doesn't highlight it.
How can I tell Vim to highlight it as a Bash script?
I start typing #!/bin/bash at the top of the file, but it doesn't make it work.
Are you correctly giving the shell script a .sh extension? Vim's automatic syntax selection is almost completely based on file name (extension) detection. If a file doesn't have a syntax set (or is the wrong syntax), Vim won't automatically change to the correct syntax just because you started typing a script in a given language.
As a temporary workaround, the command :set syn=sh will turn on shell-script syntax highlighting.
The answers so far are correct that you can use the extension (like .sh) or a shebang line (like #!/bin/bash) to identify the file type. If you don't have one of those, you can still specify the file type manually by using a modeline comment at the top or bottom of your file.
For instance, if you want to identify a script without an extension as a shell script, you could add this comment to the top of your file:
# vim: set filetype=sh :
or
# vim: filetype=sh
That will tell vim to treat the file as a shell script. (You can set other things in the modeline, too. In vim type :help modeline for more info.)
Actually syntax highlighting is a feature of vim not vi.
Try using vim command and then do
:syntax on.
I came to this answer looking for specifically how to highlight bash syntax, not POSIX shell. Simply doing a set ft=sh (or equivalent) will result in the file being highlighted for POSIX shell, which leaves a lot of syntax that's valid in bash highlighted in red. To get bash highlighting:
" Set a variable on the buffer that tells the sh syntax highlighter
" that this is bash:
let b:is_bash = 1
" Set the filetype to sh
set ft=sh
Note that if your ft is already sh, you still need the set command; otherwise the let doesn't take effect immediately.
You can make this a global default by making the variable global, i.e., let g:is_bash = 1.
:help ft-sh-syntax is the manual page I had to find; it explains this, and how to trigger highlighting of other flavors of shell.
Vim can also detect file types by inspecting their contents (like for example if the first line contains a bash shebang), here is a quote from filetype.txt help file:
If your filetype can only be detected by inspecting the contents of the file
Create your user runtime directory. You would normally use the first item of the 'runtimepath' option. Example for Unix:
:!mkdir ~/.vim
Create a vim script file for doing this. Example:
if did_filetype() " filetype already set..
finish " ..don't do these checks
endif
if getline(1) =~ '^#!.*\<mine\>'
setfiletype mine
elseif getline(1) =~? '\<drawing\>'
setfiletype drawing
endif
See $VIMRUNTIME/scripts.vim for more examples.
Write this file as "scripts.vim" in your user runtime directory. For
example, for Unix:
:w ~/.vim/scripts.vim
The detection will work right away, no need to restart Vim.
Your scripts.vim is loaded before the default checks for file types, which
means that your rules override the default rules in
$VIMRUNTIME/scripts.vim.
Vim can detect the file type reading the first line. Add the following line as first line.
#!/bin/sh
For those who have a variant of this question i.e. how to enable syntax highlighting on bash files without .sh extension automatically when opened...
Add filetype on in your .vimrc. This enables file type detection by also considering the file's contents. For example, bash scripts will be set to sh file-type. However, typing the #! won't trigger file type detection on a new file created with vim and you will need to use set ft=sh in that case. For more info, type :h filetype in vim.
As mentioned in the comments, you will need to use this in conjuction with syntax enable to turn on highlighting.
Or you could use :filetype detect.
From the doc:
Use this if you started with an empty file and typed text that makes
it possible to detect the file type. For example, when you entered
this in a shell script: "#!/bin/csh".
Once you add the shebang at the top of the file, save it and reload it (e.g. :w|e) and syntax coloring can kick in.
See also Vim inconsistently syntax highlighting bash files, the accepted answer may help as well.
vim already recognizes many file types by default. Most of them work by file extensions, but in a case like this, vim will also analyze the content of the file to guess the correct type.
vim sets the filetype for specific file names like .bashrc, .tcshrc, etc. automatically. But a file with a .sh extension will be recognized as either csh, ksh or bash script. To determine what kind of script this is exactly, vim reads the first line of the file to look at the #! line.
If the first line contains the word bash, the file is identified as a bash script. Usually you see #!/bin/bash if the script is meant to be executed directly, but for a shell configuration file using a simple # bash would work as well.
If you want to look at the details, this is implemented in $VIMRUNTIME/filetype.vim.
Probably the easiest way to get syntax highlighting on a new file, is to just reload it after writing the shebang line. A simple :w :e will write out the file, reload it, and interprete the shebang line you have just written to provide you with the appropriate syntax highlighting.
If you already know the file-type before opening the script or if you're creating a new script without an extension which is common, you can pass it to vim on the command-line like so:
vim -c 'setfiletype sh' path/to/script
vim -c 'setfiletype python' path/to/script
To toggle syntax highlight on/off while you're inside the editor.
Turn on
:syntax on
Turn off
:syntax off
Run this to always have syntax highlighting on when opening vim.
echo ":syntax on" >> ~/.vimrc
When you create a new file, only the filename detection comes into play; content detection (#!/bin/bash) doesn't apply if you type it after creating a new buffer.
The sensible thing is to just do :set ft=bash the first time around, and the next time you edit it, the #!/bin/bash will set the right filetype automatically.

Resources