Given the following simple Makefile:
#Makiefile
ifeq(,)
else
endif
According to this, it's enough to just include this matchit.vim file, which could be found among bundled plugins.
Unfortunately, it doesn't for me. Originally, I thought my other plugins might be conflicting with matchit. However, empty setup of vim doesn't work either. According to the doc of matchit, it requires b:match_words to cycle through them. Since matchit.vim is one global plugin, the b:match_words is defined in the corresponding file type plugin. verified in vim.vim, that could be found in standard runtime directory.
Am I missing something?
PS: Right now, I have to add this to my local make.vim to make it work.
#make.vim
let b:match_words='\<ifeq\>:\<else\>:\<endif\>'
The filetype for Makefiles is make. In my recent $VIMRUNTIME/ftplugin/make.vim (dated 2006 Jun 17), there is no definition for b:match_words.
Therefore, you indeed have to add the definitions to your own configuration, preferably in ~/.vim/after/ftplugin/make.vim.
If you think this is generally useful and should be included by default, you could send a patch to the script's maintainer (Bram Moolenaar).
#Ingo Karkat Thanks for the info. I have sent the path to Bram Moolenaar. Hopefully, it will appear in the next release. If anyone is eager, try to put this in your ~/.vim/after/ftplugin/make.vim.
" matchit.vim
if exists("loaded_matchit")
let b:match_words =
\ '\<if\(n\)\=\(eq\|def\)\>:\<else\>:\<endif\>,' .
\ '\<define\>:\<endef\>'
endif
PS: Due the order of vim scripts are loaded, ~/.vim/ftplugin is loaded before standard ftplugin, so it's preferred to put customized ftplugin in the ~/.vim/after/ftplugin directory, if one just want to build ftplugin on top of standard ftplugin.
Thank #pevik for fixing the missing comma. Not sure why the change is rejected, but I added it manually.
Related
I am using Vim editor v7.4 .
I have a huge C Code library , and i make constant changes to it.
Is there a way ( before compilation) to know if a function i am adding to some file is defined for this file.
Thanks
I'm not sure to correctly understand your need. In my definition, when I add a function to a file, I add its definition, so it's defined. But when I'm using a function in a file, I only need its declaration. Then there is also the problem of being sure that a function defined in a translation unit is declared somewhere (privately in the same TU as a static function, or in a header file).
For the latter, I have a solution (that checks functions definitions and declarations are balanced in lh-cpp). For the case of being sure a function is declared in the UT it's used, it won't be that simple: we need to do the preprocessor work (and recursively follow includes) and search whether a function is indeed declared. It's not impossible, but it's best to have vim know the paths where header files are in order to look for them.
Look at a tool like exuberant ctags. It parses C-style files to find any identifier and store them in a tag file, so that each of them can be accessed quickly, inside Vim for example.
Once installed, in the shell command line, you have to create a tag file with this kind of command:
$ ctags *.c *.h
This will create an new file called tags, where all the c files and header files in the current directory are parsed. Please note that there are many options for this tool (like recursively include all lib headers, which can lead to a huge file, though), you may look at the doc for more details.
Once done, in Vim, there are several commands to use transparently the infos in this file. First check your current directory is the same as the tag file; then, to check if an identifier (like a function name) is already present in the tag file, you can use:
:ts myFunctionName
I don't think tag is a good enough solution to check whether function is defined. The flexibility of C syntax make it worse, because most tag tool is syntax-based other than semantics-based.
For example, at present, the most powerful code-completion plug-in for vim is
YouCompleteMe, which is semantic-based by virtue of Clang.
So IMHO, the answer to your question is: compile it!
In order to do compiling more convenience, you can add the following configuration in your .vimrc.
map <F6> :make install<CR>
After this, when you press F6, compiler will be launched to check your code.
I started using AutoComplPop for automatic code completions. It works great on the single file I am editing, but if file1 is making a reference to a method defined in file2, it doesn't find it.
The docs don't specify if there is a way to make it search a whole project directory, or even just all open buffers, so I can't tell if this is simply not something the plugin does, or if I need to enable something.
I was testing it out on two Ruby files, if that's relevant. Thanks!
Looks like that the cause of the problem is that ACP set the complete option for its purposes to .,w,b,k (see line #125 in autocomplpop/plugin/acp.vim),
call l9#defineVariableDefault('g:acp_completeOption', '.,w,b,k')
while the default value that is used when pressing \<C-n> is .,w,b,u,t,i. And it appears that the very last letter i actually makes the difference: for some reason vim would not use word from an include file opened in a buffer to complete words in another buffer. So, b option is not enough, i must also be included. Adding the following line into my .vimrc helped
let g:acp_completeOption = '.,w,b,u,t,i'
At least it worked for C++ files, but I'm not sure it fixes the problem for the case of Ruby scripts.
Depending on what is on the left of the cursor, ACP (like all the alternatives) decides what completion mechanism to use.
But ACP only uses Vim's default completion mechanisms: if <C-x><C-o> and <C-n>/<C-p> don't provide what you are looking for, ACP won't help. Try them out first.
Oh cool, this plugin looks a lot like neocomplcache but maybe cleaner...looks a little old. Little concerning that there are so many open tickets on that project and no updates in two years.
Anyway, according to the documentation it doesn't...really...say. Very likely its one of the following things:
Your pwd. If the root directory for your source is some/path then that should also be your current working directory. Try typing :cd some/path to see if that makes a difference.
The runtime path rtp. See if adding the directory with your source files to &rtp does the trick.
The path. Same deal as the &rtp setting.
Very likely this plugin is just falling back on the built in ruby omni completion functions bundled with vim. Try help ft-ruby-omni.
I just had the same problem, and I actually found a solution for this.
Apparently you have to set in your .vimrc file the following:
let g:acp_behaviorKeywordCommand = "\<C-x>\<C-i>"
This will make acp look in every file included by your source for completions, as if you were actually typing <C-p>. However, it is slow, after trying it I decided to revert using <C-p> when there are no matches and default behaviour in the other cases.
I recently upgraded to gvim 7.3 and was pleased to find markdown highlighting. I also noticed that it treats "internal" _(underscore) as a marker. For example:
I want gvim to display emphasis here
but not_here
gvim actually displays the last line in my example as 'but not_here". It looks like SO's markdown interpretation is closer to what I want.
I do not say that gvim is "wrong" because I do not know what the correct markdown implementation is. However, is there a way to configure it so that the markers should be treated as normal text if they are surrounded by non-whitespace?
The runtime files (especially if you use the old Vim 7.3.000 / 046 installer found on vim.org) aren't updated frequently. Most plugin authors publish more recent releases elsewhere, and they are only occasionally picked up by Vim.
In Tim Pope's repository, you'll find a newer version (that you can install into your ~/.vim directory) that doesn't show the problem; instead, it even highlights the single underscore character as an error.
I have found a solution, which works in the things I have tested sofar.
Copy the %vim%/syntax/markdown.vim file into %/.vim/syntax/markdown.vim and change line 63 into:
syn region markdownItalic start="\s_\S\#=" end="\S\#<=_\|_\S\#=" keepend contains=markdownLineStart
Restart vim and it should match *this* and _this_ but not_this.
EDIT: Changed information, thanks to #ZyX
I had these issues when documenting code in markdown files.
The solution I used was to put the offending sections in a codeblock with four spaces or in a code span with surrounding back ticks (`).
Try to use Github flavor markdown: https://github.com/jtratner/vim-flavored-markdown
I have this line in my .vimrc file:
set directory=~/.vim/swapfiles//
(Note that one extra slash makes the directory names to be included instead of just file names to reduce conflict)
The above config works fine on my Linux machine, but the problem is when I use the same file on Windows I get some warning about the file cannot be read. That's probably because vim is looking for ~/.vim/swapfiles/ directory, which Windows unfortunately don't have.
Is there any way to store my swap files on Windows somewhere (better if it could be in C:\Program Files\Vim\vimfiles\)?
CASE #2
If you got answer for my above question, here is the another one. I also have some lines similar to this:
autocmd filetype python source ~/path/to/file/python.vim
Windows confuses at this point too. How can I patch up?
If you don't want to introduce a $MYVIM variable as ZyX suggests, maybe an alternative is placing the runtime files in $HOME/.vim instead of the default $HOME/vimfiles on Windows. You can then use ~/.vim/... everywhere. This also helps with synchronizing the files across multiple mixed-platform machines.
" On Windows, also use '.vim' instead of 'vimfiles'; this makes synchronization
" across (heterogeneous) systems easier.
if has('win32') || has('win64')
set runtimepath=$HOME/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/after,$HOME/.vim/after
endif
Maybe what you want is to have directory set based on the entries in runtimepath? Try this:
let &directory = substitute(&rtp, ",", "/swapfiles//,", "g")
With the default runtimepath setting on Unix-y systems you get
$HOME/.vim/swapfiles//,
$VIM/vimfiles/swapfiles//,
$VIMRUNTIME/swapfiles//,
$VIM/vimruntime/after/swapfiles//,
$HOME/.vim/after//
and on Windows
$HOME/vimfiles/swapfiles//,
$VIM/vimfiles/swapfiles//,
$VIMRUNTIME/swapfiles//,
$VIM/vimfiles/after/swapfiles//,
$HOME/vimfiles/after/swapfiles//
I agree, the after directories are unwanted, but vim will pick the first directory that exists and allows file creation so if you don't create the swapfiles sub-directory they won't be touched.
You might want to consider prepending these to the default value instead of replacing it so the defaults are available as a fallback if none of the directories exist.
I don't understand why you have the auto commands you mention. The default settings of runtimepath with filetype plugin on should take care of that for you.
Of course you always have the option of explicitly checking the platform and using different settings as in
if has("win32")
" settings for windows
elif has("win32unix")
" settings for cygwin
elif has("unix")
" settings for unix
elif has("macunix")
" settings for macosx
endif
If you want to avoid an error if a file does not exist then you can use the following definitions in your vimrc
func! Source(file)
if filereadable(a:file)
exec "source " . fnameescape(a:file)
endif
endfunction
com! -nargs=1 -complete=file Source call Source(<f-args>)
and change source to Source when the file might not exist.
First of all, vim translates all forward slashes to backward on windows thus it won’t hurt having slashes. Just in case you think it can be a source of trouble.
Second, it is not impossible to have ~/.vim and all other directories on windows, just some programs don’t want to work with names that start with a dot. You may just add this to runtimepath as it is not there by default on windows and move all user configuration there.
Third, in most places you have a filename you may use $ENV_VAR. It includes setting &rtp, &directory and using :source. So the solution may be the following:
if has('win16') || has('win95') || has('win32') || has('win64')
let $MYVIM=$HOME.'/vimfiles'
else
let $MYVIM=$HOME.'/.vim'
endif
set directory=$MYVIM/swapfiles
autocmd FileType python :source $MYVIM/after/ftplugin/python.vim
(though I agree with #Geoff Reedy that there should be no need in using the last line).
And last, modifying and storing something in C:\Program Files is not the best idea, neither for you nor for the program itself (by the way, vim won’t modify or store something there unless you told it to). It is to be modified by installation, update and uninstallation processes, not by anything else.
I fully agree with Geoff Reedy that the autocmd shouldn't be necessary. In other cases, you can use :runtime instead of :source. It will automatically search all (user and system directories in 'runtimepath'.
I have a warning I can not easily remove from my build, every time i run ":make" from inside vim the quickfix takes me to some header file I don't care about. How can I prevent VIM from doing this and only showing me warnings and errors I do care about?
As Luc Hermite said, it is possible to ignore warnings using 'errorformat'option.
Adjusting this option is a little bit complicated; it may be helpful to check $VIMRUNTIME/compiler for some examples.
When working with avr-gcc and C++ some annoying warnings like this
tests.cpp:492: warning: only initialized variables can be placed into program memory area
shows up, and it is likely to be result of a compiler fault.
To avoid that this warnings being displayed on quickfix window I've add this to ~/.vimrc:
compiler gcc
set errorformat^=%-G%f:%l:\ %tarning:\ only\ initialized\ varia
\bles\ can\ be\ placed\ into\ program\ memory\ area
The %-G can be used to specify patterns to be ignored.
The ^= in set errorformat^=... is used to prepend the ignored warning pattern to 'errorformat' -- using += (set errorformat+=...) would append to the option and wouldn't work, as 'errorformat' is a list of formats and the first one that matches is used, thus the "normal" warning pattern would apply instead.
Maybe you could adapt these settings for your environment.
Check :h 'errorformat' (aka &efm), there are options to ignore warnings as long as you can recognize them with a pattern.
A quick and dirty way would be to write a simple shell script that runs your make and greps out the warnings you don't want to see. Then have vim use this script instead of make (Add "set makeprg=yourscript.sh" to your .vimrc).
To build on what mMontu suggested, adding this to my .vimrc did the trick for me (ignore all warnings from my gcc compiler)
set errorformat^=%-G%f:%l:\ warning:%m
Learn from Bram himself.
I can vaguely remember he talks about this somewhere in this video.
He adds a filter to ignore some gnome warnings when he's compiling gvim.
The video's well worth watching anyway.
It's around the 30 minute mark.