override python filetype detection in vim - vim

I'm trying to detect buck's TARGETS file as 'buck' files instead of 'python', which is the filetype vim's currently detecting for them.
I tried to add autocmd BufRead,BufNewFile **/TARGETS set filetype=buck to my .vimrc but it didn't seem to work.
What's the correct way to change a 'default' detected file type ?

Your autocmd is the way to go in principle; just omit the **/ in the pattern:
autocmd BufRead,BufNewFile TARGETS set filetype=buck
see :help autocmd-patterns
Ideally, you'd have this line in a .vim/ftdetect/buck.vim file

Related

Make vim recognise COOL syntax

I am using vim 8.1 on macOS (vim-plug for plugin management). I need to work with COOL files, so I manually downloaded the syntax file and put it in ~/.vim/syntax
I added the following line to my .vimrc in order to associate the .cl extension with COOL:
au BufNewFile,BufRead *.cl setf cool
However, when I load .cl files into vim, it fails to recognise the language.
:verbose set ft ?
yields:
filetype=lisp
Last set from /usr/local/Cellar/vim/8.1.0650/share/vim/vim81/filetype.vim line 875
Changing the .virmc line to:
au BufNewFile,BufRead *.cool setf cool
makes vim recognise the files as COOL.
What should I do in order to have .cl default to COOL instead of LISP?
Create the file ~/.vim/filetype.vim with the following content:
augroup filetypedetect
au BufNewFile,BufRead *.cl setf cool
augroup END
See :help new-filetype.

Vim colorscheme not loading when using autocommand BufNewFile

When trying to automatically open the corresponding .cpp or .h file using autocommand I encounter no colorscheme on the corresponding file that is opened.
I'm not too familiar with vimscript but I believe Vim is opening the file thinking it is of file type ".txt" and therefore using a default colorscheme.
Two autocommand lines in ~/.vimrc:
au BufRead,BufNewFile *.cpp exe "bel vsplit" fnameescape(expand("%:r").".h")
au BufRead,BufNewFile *.h exe "vsplit" fnameescape(expand("%:r").".cpp")
Any help would be appreciated.
Your answer is a workaround (though you should use :setlocal instead of :set to avoid that the syntax leaks out to new buffers that are opened from that one), but it doesn't attack the root cause, which you'll find explained at :help autocmd-nested:
By default, autocommands do not nest. If you use ":e" or ":w" in an autocommand, Vim does not execute the BufRead and BufWrite autocommands for those commands. If you do want this, use the "nested" flag for those commands in which you want nesting.
Syntax highlighting (you say colorscheme in your title, but that's actually just the color and font attributes that are then used by syntax highlighting) is based on :autocmd events (same goes for filetype plugins, so any C++-related settings you also wouldn't find in the split file, assuming you have :filetype plugin on in your ~/.vimrc). Without the nested attribute, the split file will be opened, but none of the usual actions will be run on them. Though nesting in general can be problematic, this is one of those cases where it is needed.
au BufRead,BufNewFile *.cpp nested exe "bel vsplit" fnameescape(expand("%:r").".h")
au BufRead,BufNewFile *.h nested exe "vsplit" fnameescape(expand("%:r").".cpp")
Unfortunately, this introduces another problem: The one autocmd will trigger the other one, and vice versa (up to a limit). You need to guard the actions so that a split is only done if the file isn't open yet. (This also improves on the usability in a general way, when you open a file with the other already open.) :help bufwinnr() checks whether the target buffer is already visible in a window:
au BufRead,BufNewFile *.cpp nested if bufwinnr("^" . expand("%:r").".h$") == -1 | exe "bel vsplit" fnameescape(expand("%:r").".h") | endif
au BufRead,BufNewFile *.h nested if bufwinnr("^" . expand("%:r").".cpp$") == -1 | exe "vsplit" fnameescape(expand("%:r").".cpp") | endif
If anyone cares to look at this in the future the solution was that Vim was loading the second file as syntax=none. So adding | set syntax=cpp at the end of each auto command fixed it.

Why doesn't vim recognize a new file type?

I am trying to get vim to recognize a filetype.vim file consisting of the following:
if exists("did_load_filetypes")
finish
endif
augroup autodetect
au! BufRead,BufNewFile *.ish setfiletype perl
augroup END
This file is in the directory ~/programs/vim
My .vimrc file contains the following line:
set runtimepath=~/programs/vim,$VIMRUNTIME
I checked that this line is being executed by typing ":set runtimepath?" The result is "runtimepath=~/programs/vim,/usr/share/vim/vim74".
But when I open a file such as ish.ish, the vim filetype variable is set to 'on'. When I open x.pl, the vim filetype variable is set to 'perl'.
I can fix the problem by copying (or moving) filetype.vim to the ~/.vim directory (without changing runtimepath). Why doesn't vim recognize filetype.vim in ~/programs/vim?
The 'runtimepath' option is meant to tell Vim where to look for "standard" *.vim files such as colorschemes and plugins. Try :echo &rtp in a clean Vim session to see what it should look like and read :help 'runtimepath'. By setting this option to a meaningless value you effectively make Vim unable to find those files and thus work correctly.
To add a specific directory to 'runtimepath', use the following syntax:
set runtimepath+=/path/to/directory
But what's the reason you'd want to use a non-standard directory for standard scripts? What's wrong with ~/.vim?
The most obvious way to tell Vim about a new filetype is to add these lines to your ~/.vimrc:
augroup autodetect
autocmd!
autocmd BufRead,BufNewFile *.ish set filetype=perl
augroup END
The cleanest way is to put this line in ~/.vim/ftdetect/ish.vim:
autocmd BufRead,BufNewFile *.ish set filetype=perl

What exactly happens when you change a file type in vim?

If I have an apache file in /etc/apache2/sites-available/www.example.com and I set its filetype like so
:set filetype=apache
What does that do? Does that change the file at all? Is it only reflected in the instance of vim? The session of vim? I can manually set the filetype, but then vim warns me that I am in read only mode (/etc/apache2 needs root access). If I open vim as root, I won't get the warning, but if I leave and open it again (as normal or root), the filetype is gone. How do I make this more permanent, at least when called from the same session file
set filetype changes the way vim handles the file, by invoking all the FileType autocommands. It does not persist. If you want to always open that file with filetype=apache, try adding this into your .vimrc:
au BufRead,BufNewFile /etc/apache2/sites-available/www.example.com set filetype=apache
You can read more about it in:
:help 'filetype'
:help filetypes
:help :autocmd
:help .vimrc
EDIT: as found in my /usr/share/vim/vim73/filetype.vim:
au BufNewFile,BufRead access.conf*,apache.conf*,apache2.conf*,httpd.conf*,srm.conf* call s:StarSetf('apache')
au BufNewFile,BufRead */etc/apache2/*.conf*,*/etc/apache2/conf.*/*,*/etc/apache2/mods-*/*,*/etc/apache2/sites-*/*,*/etc/httpd/conf.d/*.conf* call s:StarSetf('apache')
s:StarSetf will setfiletype to apache if the filetype doesn't match an ignored pattern. On my system, :echo g:ft_ignore_pat will show only archive file extensions as ignored. setfiletype does set filetype, but only once.
So, at least on my system, the pattern */etc/apache2/sites-*/* would catch your filename and make it an apache file.
The filetype basically lets Vim change settings for 'types of files'. The way it does this is by firing auto command for the FileType category when you change the filetype. This could potentially change your file if an auto command for FileType is applicable for your file (but generally plugin developers use it for r/o type changes that affect highlighting, and not the contents of the file).
If you are worried that setting the filetype is mucking with your file you can see what FileType autocommands exist by issuing the following command:
:au FileType
To setup your apache files to be apache filetypes you can put something like the following into your ~/.vimrc:
:au BufRead /etc/apache2/sites-available/* set ft=apache

Disabling autocommenting for all filetypes

I turned on filetype plugin for some rails vim plugins I added, but a side effect of this seems to be that now autocommenting has been enabled in all filetypes (for instance, if I start a line with #, the next line, either by Enter in insert mode or O, etc. to enter insert mode, will also get a #).
I found a guide to disabling the auto-commenting formatoptions, and added the following to my .vimrc:
au FileType * setlocal formatoptions-=cro
However, I am still running into problems -- unless I explicitly :source .vimrc, (or enter the setlocal ... directly), it is not taking effect. I determined that this is the case because vim's ftplugins are overriding my options with their own.
I then found a second guide which talks about using an after ftplugin script to make changes after the ftplugin scripts have run, however their solution is to create symlinks for every single filetype in ~/.vim/after/ftplugin to a central file, and this seems to be kludgy to me.
Is there any way to create a generic after-ftplugin script or am I approaching this problem incorrectly? Any help would be appreciated.
How about an "after" plugin? Create a file in ~/.vim/after/plugin/ called noAutoComments.vim (or whatever) and place your autocmd in that?
Edit:
The reason this works? I'm only guessing here, but I have a feeling that the autocmd in the ~/.vimrc file is getting removed by some other file (but before the "after" files are getting sourced).
I ended up removing my ~/.vim directory and replaced my ~/.vimrc with the following 3 lines:
filetype plugin on
syntax on
au FileType * setlocal formatoptions-=cro
With only these lines in my ~/.vimrc and no ~/.vim/ directory, the autocmd seems to work as expected (Vim 7.1).
For any file that I edit:
:verbose set formatoptions?
formatoptions=ql
Last set from ~/.vimrc
I have yet to determine what file (plugin) is causing this issue however.
I've done some more investigation and it seems that the location of my autocmd within my .vimrc file determines if formatoptions will be overridden by vim's ftplugins or not. Using vim --noplugin to disable all external plugins, I found the following results:
If my vimrc looks like:
au FileType * setl fo-=cro
filetype plugin indent on
The result of :verbose set fo? is:
formatoptions=croql
Last set from /usr/share/vim/vim72/ftplugin/ruby.vim
However, if the lines in my vimrc are reversed:
filetype plugin indent on
au FileType * setl fo-=cro
The result of :verbose set fo? is:
formatoptions=ql
Last set from ~/.vimrc
... which is the desired result. So it seems that the autocmd needs to be specified after filetype plugins are enabled.
Another reason this might not be taking effect...
From :he :set-=:
When the option is a list of flags, {value} must be
exactly as they appear in the option. Remove flags
one by one to avoid problems.
I have
" Turn off auto-commenting
au FileType * setlocal formatoptions-=c
au FileType * setlocal formatoptions-=r
au FileType * setlocal formatoptions-=o
because I've run into this.
Using one of the various autocmd events to set the configuration option should work if you find the right one, but I'd start by running:
:verbose set formatoptions?
This will tell you where the option was set, which may make it easier to determine which autocmd to use. Alternatively, if you don't mind a bit of minor hacking, the way I'd probably do it is just to find out where it's set in the plugin and comment out that line (and make a note of it in case you ever upgrade the plugin). You could also contact the plugin's author and ask them to make it a configurable option.
For the available autocmd events, read this:
:help {event}
I have tried solutions proposed by many, but none of them worked for me, but I found one very simple workaround, namely, in your ~/.bash_aliases:
# vim without auto comment
alias vi="vi +'set fo-=cro'"
I was struggling with this issue and I finally works with the following lines:
syntax on
filetype on
filetype plugin on
au FileType * setlocal formatoptions-=cro
I think the key here is that the autocmd is place after the filetype plugin on.

Resources