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.
Related
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
By default Vim is looking for plugins and other stuff in ~/.vim.
Is there any way to tell Vim to search for plugins, etc. in ~/.other_folder and force it to ignore ~/.vim entirely?
Vim uses the comma-separated paths from 'runtimepath' to determine where to look for :runtime'd files.
You can change that option either in ~/.vimrc (which is sourced as the very first script), or by passing the set rtp=... commands on Vim's command-line via --cmd (the commands passed with -c are only applied after startup).
When I open some bash script files with vim it sometimes identifies them as conf files, that's okay, I can just correct that by setting the filetype to sh with :setf sh.
That great, except I've noticed that this doesn't fix things entirely:
Notice that shopt is properly highlighted on the left, but not on the right, where I manually set the filetype to sh.
This means that when a file is identified as bash or sh by vim, it sets the filetype to sh but then does some extra steps that I'm not doing when I set the filetype manually.
Any one know what that might be, and how I could fix it?
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, for some other shell configuration file you should use the file extensions .bash.
The help in vim explains this as well at :help ft-bash-syntax. You can also use let g:is_bash=1 in your .vimrc to make bash syntax highlighting the default for all files with filetype=sh. If you want to look at the details, this is implemented in $VIMRUNTIME/filetype.vim.
It turns out that syntax/sh.vim includes specific highlighting for Korn, Bash and sh, you just have to tell it which you're using. This is done with b:is_kornshell, b:is_bash and b:is_sh respectively.
Depending on the situation I figure I'll use the following:
ftdetect/bash.vim:
au BufRead,BufNewFile *bash* let g:is_bash=1
au BufRead,BufNewFile *bash* setf sh
Modeline:
# vim:let g:is_bash=1:set filetype=sh:
Key Mapping
nmap <silent> <leader>b :let g:is_bash=1<cr> :setf sh<cr>
Similar to Peter Coulton's solution and documented as well as an alternative in the section "new-filetype" of the "filetype" Vim help the ~/.vim/filetype.vim file could contain the following code:
if exists("did_load_filetypes")
finish
endif
augroup filetypedetect
au! BufRead,BufNewFile *bash* let b:is_bash = 1 | setfiletype sh
augroup END
This approach has the following implications:
There is one ~/.vim/filetype.vim file instead of one for each file type under the ~/.vim/ftdetect directory.
The b:is_bash variable is set local to the buffer as opposed to global by referring to it as g:is_bash.
Try viewing the effective syntax setting
:windo echo b:current_syntax
(I kind of expect the first window to say bash, and the second to say sh...?)
Also try mucking with the synatx synchronisation:
:windo syn sync fromstart
:windo syn sync minlines=300
In general
:he syn-sync
for more information
PS.
A long shot, but some other highlighting might be interfering:
:windo se #/=''
:match none
:2match none
:3match none
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
I have multiple plugins in Vim and some of them modify the default behavior of Vim. For example I use Vimacs plugin, which makes Vim behave like emacs in the insert mode alone. Sometime I want to turn off the Vimacs plugin without moving the vimacs.vim out of the plugins directory. Is there a way to do it?
You can do this if you use a plugin manager like Vundle or Pathogen, which will keep the plugin in its own directory underneath the ~/.vim/bundle/ directory.
In that case, just find out the runtimepath of the vimacs plugin with the following command:
set runtimepath?
Let's say it's ~/.vim/bundle/vimacs.
Then, put this command in your .vimrc:
set runtimepath-=~/.vim/bundle/vimacs
To load vimacs, just comment that line out and relaunch Vim (or source your .vimrc).
See which variable vimacs check on start. On the begin of the script file find something Like if exists('g:vimacs_is_loaded").... Then set this variable in your .vimrc or while start vim with vim --cmd "let g:vimacs_is_loaded = 1".
In case you are using pathogen, this post gives a better answer, in my opinion. Since I have frequent need to disable snippets when using latex, also added this in my ~/.config/ranger/rc.conf:
map bs shell vim --cmd "let g:pathogen_blacklist = [ 'ultisnips', 'vim-snipmate' ]" %f
This way, whenever I want to open a file with snippets disabled, it is easy.