I just installed ntpeters/vim-better-whitespace plugin and it defines a EnableWhitespace function which is really annoying since I'm used to typing :E to get the Explorer and now there is a conflict (Ambiguous use of user-defined command).
Is there a way to remove this function in my vim.rc file (i.e. some magical 'unbind_function EnableWhitespace') and leave the plugin code intact?
The plugin also provides a ToggleStripWhitespaceOnSave, so I will not miss any functionality.
Thanks in advance.
EnableWhitespace is a user command, not a function (there is a function with that name but that's not relevant). You can delete it with:
:delcommand EnableWhitespace
Related
I'm trying to configure gf to open files under the cursor.
It works always... almost.
I found an issue when the text under the cursor has unfortunately a corresponding directory. In that case, netrw plugin is opened.
Let me give you an example. I am in this code:
[...], MyObject myobject, [...]
I am over MyObject and press gf.
Unfortunately I have in a folder:
myobject <-- a directory
MyObject.java <-- the file to open
netrw is activated.
I tried to check doc to tinker a little bit (suffixesadd, ...), but probably I am missing how to do it properly.
I found this answer, but it is a little bit different in my opinion because in that case the match of the text and the directory were the only 1st one and it was perfect.
Any help?
P.S. what I am trying to do is creating a small vim plugin that could be used to navigate Java projects based on Maven (it's called vim-java-maven).
Just for learning VIM.
As silly as it may sound, Vim considers directories as valid targets so…
:help 'suffixesadd' doesn't help because the directory name is an exact match,
:help 'includeexpr', which is only invoked if there is no match, is not invoked since there is a match.
That behaviour is hardcoded and there is no way to affect it at runtime. The only solution is to write your own Gf() that handles directories more sensibly and map it to gf.
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 think I understand the difference between function and function!: if a function with the same name already exists function! silently replaces it, but function yields an error.
I end up using function! always. Because if I use simple function sooner or later it returns and bites me with:
E122: Function my_lib#MyHandyFunction already exists, add ! to replace it
Are there any situations when one should use simple function without !?
In scripts, it doesn't hurt to use :function!, but you should use script-local (s:Foo) or autoload-scoped (myscript#Foo) functions to properly namespace them. So, the override error for :function is helpful to alert you to redefinitions of global functions, but in scripts, you shouldn't need this precaution.
You have to use :function! when you want to reload the script during development (instead of restarting the whole Vim). (And plugins like my ReloadScript plugin can deal with the include guards.)
Another empirical point: Most of the plugins I have use :function!, probably for the easy reload.
The same goes for :command! and :normal!, where (usually), the version with ! should be used.
You should normally use function. Doing such, you would at least recognize when there's a name collision.
When using function! by default, you don't have any feedback that you're about to override an existing function (i.e. change existing functionality)!
Just have a look at the error message you've posted:
E122: Function my_lib#MyHandyFunction already exists, add ! to replace it
This means: careful, dude! If you use function! now, the users of my_lib#MyHandyFunction will experience things they never expected!
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.
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.