CloseSIngleConque not an editor command - vim - vim

I have been using these dotfiles for my vim configuration among other things:
https://github.com/skwp/dotfiles
I recently updated the files and some of the control-p stuff has stopped working
If I select ,b I get the following error:
Not an editor command CloseSingleConque
If I look at the settings file for ctrl-p I see the following mapping:
nnoremap <silent> ,b :CloseSingleConque<CR>:CtrlPBuffer<cr>
My vim installation does not recognise CloseSingleConque. Does anybody know why this is?

Taking all your settings from random internet strangers is not a very good idea.
:CloseSingleConque<CR> is in the ruby-conque plugin that is part of this "distribution". Do you have it installed? If not, you can safely remove this part of the mapping. If it's installed, that's a bug that you should report to the author.
Take this problem as an opportunity to think again about using someone else's "distribution" versus rolling your own, progressively.
Seriously, who needs 80 plugins, including two overlapping fuzzy file/buffer navigators and another which is already bundled with Vim?

Related

How to add Syntax Highlighting in Vim for .ini files

I recently started using Vi Improved and being a Rainmeter Skin Specialist, when editing my .ini files I can't find a way to add syntax highlight for such files. I searched for a lot of time on stack and git and turned up to nothing. Requesting help at the latest.
TLDR; Need .ini file syntax highlighting for Vim
Vim already has syntax highlighting for *.ini files.
If your Vim is reasonably recent, say 8.0 and up, and you didn't set anything up with regards to Vim (no $HOME\_vimrc, nothing), then your *.ini files should be highlighted without any human intervention at all.
The screenshot below was taken in a test VM with a basic Vim without any setup:
If you have already customised Vim, with a $HOME\_vimrc file and/or with a $HOME\vimfiles directory, then you are in full control, which means that the automatic stuff described above is no longer done for you anymore. And being in full control of Vim pretty much requires that you learn it properly and configure it as you go.
Having EITHER of the following lines in your $HOME\_vimrc or $HOME\vimfiles\vimrc is going to give you automatic syntax highlighting for any recognised filetype:
syntax enable
syntax on

vim81 configuration wrong after I added .vimrc

I uninstalled vim74 and compiled vim81 and installed it. However I found it strange, comparing to vim74. When there's no .vimrc file under HOME dir, I open a c++ file and syntax highlight is working and I can use Backspace to delete letters. However when I add a .vimrc under HOME dir and just put set number into it, when the c++ source file is opened, no highlight, and Backspace not working. Why is that ? I used to add some configurations in .vimrc under vim74 before, and this situation never happens.
After complaints that Vim in its default configuration is hard to use (especially for beginners), it was decided to enable a default configuration if the user hasn't created his own ~/.vimrc (yet). This was introduced with Vim 8.0, and explains what you're seeing (namely: syntax highlighting and sensible backspace behavior). Read more about the details at :help defaults.vim.
The help also has instructions how to keep the defaults when adding your own ~/.vimrc configuration:
If you create your own .vimrc, it is recommended to add these lines somewhere
near the top:
unlet! skip_defaults_vim
source $VIMRUNTIME/defaults.vim
Then Vim works like before you had a .vimrc.
Tip: Don't go all crazy with adding various snippets (especially not those you don't fully understand) and plugins to your ~/.vimrc, even though the Internet is full of them. Rather, build it up gradually, depending on needs, and back up your understanding with careful studying of the excellent :help. Also, avoid pre-packaged Vim distributions; they're even worse.

Does anyone have extra «» generated from lh-brackets

Can't seem to find any reason for this, but I have been using Ycm, syntastic, and all the lh- plugins with vim for a while now. In the case of lh-brackets, I used to have a problem with it generating "«»" every time it 'automatically' generated the other bracket, paren, quote, etc. But it was only happening in .vim files, so i turned it off for vim files in my vimrc. Now nothing has changed, no new scripts installed, and all of the sudden, this happens with ALL files (cpp, h, pl, py, etc). Like i said, not using heavy customization, and everything is default except the disabling of lh-brackets when editing vim files, but that has now become a hotkey since i cant use it anywhere.
My Question is this: does anyone have this or similar problem with lh-brackets, and if so, any idea how to fix it, or is there some setting I am missing?
My first thoughts are to go though and check any updated vim scripts (this just happened a day ago) that could have been updated when doing an apt-get upgrade (like debian.vim) but after that I've got nothing...
The placeholders characters can be jumped to (:h <Plug>MarkersJumpF -> <C-J> with vim, <m-ins> with gvim). That's their purpose.
If you have installed lh-cpp, see :h lh-cpp-first-steps, you'll find a quick guide to my C++ suite (and lh-brackets incidentally).
EDIT: The plugin was badly designed. I've patched the plugin to rely on g:usemarks in order to fix the ergonomic of plugin .
In the (now-) past, if you wanted to set b:usemarks to 0, you'd have needed to add an autocommand that'd set b:usemarks to 0 in all new buffers.
Now, (lh-brackets v2.2.0), if you want to always disable the placeholders/marker characters, you need to set g:usemarks to 0, not b:usemarks. Buffer-local variables are meant to be set from ftplugins, or tree/project-local plugins which are supported thanks to plugins like local_vimrc.
And as romainl has pointed out, don't hesitate to use the bug trackers, or even to contact me.
hmm found it:
:let b:usemarks=0
now needs to be set, apparently that was a marker for integration to another plugin, though i dont use it.

vim plugin for directory list/file open

I'm looking for a vim plugin similar to http://www.vim.org/scripts/script.php?script_id=1325 with a directory list in which you can select a file to open. Does this exist somewhere? Wasn't able to find it myself.
NERDTree is the second best ranked plugin on vim.org and it perfectly fits your description.
There are many other variations of the same principle:
FuzzyFinder
LustyExplorer (the one I used before)
Command-T (famous among TextMate switchers, I never liked it, though)
CtrlP (the one I use now)
…
And I second :Explore.
Have you tried the :Explore command that comes with the standard vim distribution since (roughly) version 6?
See http://vim.wikia.com/wiki/File_explorer for basic help on that command.
See http://vimdoc.sourceforge.net/htmldoc/pi_netrw.html#netrw-quickhelp for detailed help on what the Explorer can do.
If you want to open an explorer without replacing the current buffer, you can use the :Sexplore command. A puerile mnemonic for that is to execute :Sex.

share eclim -friendly .vimrc

I am trying to to use eclim for my daily development requirements. My .vimrc has some issues preventing few functionalities like code completion etc.
It would be great if anyone using eclim regularly share your .vimrc.
You can find my vim setup on github. I use eclim to do Android development.
See visualstudioinvoke.vim for how I launch Vim from eclim. This isn't necessary, but it's useful to start at the current line in the current file. It also sets up my eclim menu, bindings, and settings.
It's best to start the eclim server (by opening the "Eclim" eclipse tab) before you start gvim.
I have eclim's code completion mapped to Ctrl-Space.
You won't get any code completion for classes that aren't in the scope of the current file. To import, I have a menu option under Eclim > ImportMissing.
However, my vimrc might be pretty alien to you, so you might be better served whittling down your vimrc until you figure out what's breaking things. The default map for completions is Ctrl-x Ctrl-u. You can use :verb map <C-x> to search for maps that start the same way and it will show you where they're defined.
If you use SuperTab, try disabling it. SuperTab and eclim are both maintained by
Eric Van Dewoestine so they should be compatible, but you may have a SuperTab configuration problem.
You could also try updating all of your plugins.

Resources