While editing .scm files it would be great if Vim would automatically put the ending brace ) as soon as I start (. How do I do this?
You can map the opening brace to your liking:
:imap ( ()<left>
Try to use AutoClose plugin.
The simplest answer is to include a map. Eg.:
:inoremap ( ()<left>
The problem is that you would need to add one entry for each symbol you want automatically closed ('{','[','"',etc). Besides, plugins are normally more smart, providing things like detecting the "closing" character and not repeating it.
The problem with the solution above and most plugins, is that they tend break the undo sequence (gundo anyone?), as explained in:help ins-special-special.
Here is list of plugins that do what you ask (from vimtips):
delimitMate by Israel Chauca Fuentes (configurable, and doesn't break undo/redo/repeat, but - break iabbr) also on GitHub
AutoClose by Karl Guertin (auto-closes specific hard-coded characters, but doesn't break undo/redo/repeat)
AutoClose by Thiago Alves (configurable, but breaks undo/redo/repeat)
auto-pairs Auto Pairs by Miao Jiang (configurable, but breaks undo/redo/repeat)
ClosePairs by Edoardo Vacchi (configurable, but breaks undo/redo/repeat)
smartinput by Kana Natsuno (configurable, but breaks undo/redo/repeat)
Besides vimtips, there is another nice explanation of the issue on the web.
I needed one too, and I already tried a few of the plug-ins:
AutoClose, http://www.vim.org/scripts/script.php?script_id=1849, is a bit aggressive.
simple pairs, http://www.vim.org/scripts/script.php?script_id=2339, depends on Python. If you are on Linux it is not a problem, but on Windows it can be a trouble to match the Vim version to the Python interpreter you have.
My advice would be ClosePairs, that you can find at http://www.vim.org/scripts/script.php?script_id=2373 which has been working perfectly for me. It is simple and useful.
There are many tips and plugins on the subject. Have a look at the relevant entry in the vimtips site.
I'm presently using auto-pairs and it works quite very well.
The issues of the the plugin breaking undo/redo/repeat seem to persist among some of the plugins listed above but i don't think its much of an issue (well, at least not to me at the moment).
Just one caveat though, i wasn't able to use :helptags to generate the help file with this plugin as at the time of writing this.
Check out this new plugin: vim-autoclose by Townk. The previously mentioned AutoClose was to aggressive, sometimes behaving in an undesirable way.
There is a problem with using this (via the imap or one of the scripts). You won't be able to repeat the complete edit by using the . command.
e.g. (foo) with . only gets you foo, without the brackets.
It works fine if you insert the brackets normally, as two characters.
You can try downloading the following plugin
AutoClose : Inserts matching bracket, paren, brace or quote
https://github.com/vim-scripts/Auto-Pairs
Tested this plugin for undu redo. 2013 It just works. Also with python-mode plugin.
There is a new plugin by cohama:
lexima.vim (github)
(not yet on vim.org)
This plugin supports the .command!
Afaik, this is the only plugin supporting this.
Also the undo/redo sequence works.
Related
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'm using the awesome https://github.com/tpope/vim-surround plugin to surround words with parenthesis, for example I often use: viws<space><space> to surround a word with spaces.
What I'm missing is the opposite of this, that is, deleting surrounding spaces around a word.
The most common use for me is function arguments like
foo(bar) vs foo( bar ) depending on code style.
Does anyone know a nice way to do this?
Note: This solution requires the surround plugin referenced in the question.
For your specific situation you could do the following:
cs()
This changes foo( bar ) to foo(bar), however, it is not a general solution to your problem.
I often productively procrastinate in search of vim plugins too, when I could just define a mapping for this.
nnoremap <leader>dd F<space>xf<space>x
EDIT more information
<leader> common key for user defined mappings (, is a good one)
dd combination to use (any other mnemonic one will suffice)
F<space>x search backwards for a space, then remove it
f<space>x search forwards for a space, then remove it
Maybe just BXElx in normal mode.
In fact, perfect solution for me is the mapping provided by #puk, but using the keys #sarnold expected in the first place (what one would expect from surround plugin if it implemented this).
This is:
nnoremap ds<space> F<space>xf<space>x
I am reading the doc still not sure what the plugin does.
https://github.com/tpope/vim-ragtag/raw/master/doc/ragtag.txt
Any further clarification will help.
Thank you.
The ragtag plugin only works with certain filetypes, which can cause some confusion, especially when editing an unsaved document.
*html*,wml,jsp,php,asp*,cf,mason,eruby,liquid,xml,xslt,xsd,docbk
It adds tags based on shortcuts. Its actually really useful for certain things.
For instance, in rails, you write the word foo (as in all the examples), press <C-X>+ and you get (^ is where your cursor ends):
<%= foo^ %>
I'm not sure this is possible, but I'm interesting in making this happen.
Ideally, I would like to map this feature to SHIFT+CTRL+3.
I'm looking for a way to have Vim enter a comment (single line) which corresponds to the syntax of the file I'm editing. If there are multiple single-line comment styles, Vim could either automatically pick one, or give me the choice. If the single-line comment has two parts (e.g. /* and */), then pressing SHIFT+CTRL+3 the first time will start the comment, and the second time will close the comment.
Examples:
Python: #
JavaScript: //
C, C++: /* with */ or //
I know there are scripts which will insert comments for you, but I haven't seen any that will do this based on the syntax of the file.
I highly recommend NERD Commenter.
Sort of! I don't believe vim will do this out of the box, but you can install plugins that will do fairly intelligent commenting (using movement keys, visual line highlighting, etc) that are specific to the filetype being edited. You can get these plugins off of vim.org, and you should be able to make your own key mappings in your .vimrc file if you don't like the ones they come with.
tComment is pretty well regarded, and has worked for me.
I've heard that EnhCommentify might be better, but I haven't used it myself.
Seems like a similar question to this:
How to comment in vim while respecting the indent?
Use the nerd commenter plugin:
http://www.vim.org/scripts/script.php?script_id=1218
See: this script which provides a function to commented a highlighted area in visual mode.
You want to start a comment in insert mode so your function would look more like:
fun CommentLines()
exe ":s#^#".g:Comment."#g"
endfun
Not quite what you're looking for, but efficient, and I suppose you know which comment to use.
(all this in command mode)
Put your cursor to the first line you want to comment. We willl then set a marker called a (valid names are a-z, single character) by typing
ma
put the cursor to the last line, then set a marker called b by typing
mb
Then comment the whole block (by searching for a newline and inserting the comment character (note the use of "#" as search delimiter because otherwise wee have to escape the "/")
:'a,'bs#^#//#
or for Python:
:'a,'bs/^/#/
To uncomment:
:'a,'bs#^//##
As we do line comments, it doesn't matter if we have other comments already in the file, they will be preserved.