I am trying to define a vim key map for putting the selected line inside an HTML p tag:
vnoremap <leader>bp c<p><cr></p><esc>P
It doesn't work, I think vim is interpreting <p> in a special way. How can I solve this?
It looks like you are using Vim in "compatible mode" which is something only hopelessly masochistic people do. In "nocompatible mode", your mapping works as expected so you should probably make sure nocompatible is set (creating a blank ~/.vimrc should be enough).
Anyway, your <p>s are not where the problem is because they are inserted normally, it's your <cr> and your <esc> that are causing a mess: since you are running Vim in "compatible mode", the cpoptions option includes < which causes Vim to not recognize <CR> and friends as special keys.
Running Vim in "nocompatible mode" is the best way to go but you can also use the following notation if you really insist on going "compatible":
vnoremap <leader>bp c<p>^M</p>^]P
where ^M is inserted with <C-v><CR> and ^] is inserted with <C-v><Esc>.
You may want to look into Tim Pope's Surround plugin. Then you can do S<p> and surround the visually selected text with <p> tags.
However the answer please see #romainl answer. I would also suggest you read up on key-notation via :h key-notation
Related
Apparently <c-space> doing something by default in vim but I can't figure out a way to check what it's doing.
:imap <c-space>
> No mapping found
:h <c-space>
> Sorry, no help for <c-space>
It's a little hard to give a fully generic answer here and sometimes your specific platform or terminal emulator might have an effect on how specific keys are seen by Vim.
One way to try to figure out which key code is seen by Vim is to go into Insert mode and then press Ctrl+V followed by your specific key. (See :help i_CTRL-V, which will tell you Vim will insert the next symbol literally.)
In my case, typing Ctrl+V followed by Ctrl+Space in Insert mode shows me ^#, which symbolizes the Ctrl+# sequence, which shows me that's how Vim is seeing this key sequence.
(I believe this is mostly universal, and Ctrl+Space will always generate Ctrl+# everywhere, but as I mentioned there are platform differences, so I can't guarantee it works that way everywhere, but you should be able to use the same Ctrl+V trick to find out if it's the same or not in your case.)
Following that finding, you can then look at :help i_CTRL-# to see that the Ctrl+# sequence (which should be equivalent to Ctrl+Space) will "insert previously inserted text and stop insert."
Is it possible to to change the way you expand emmet code into HTML?
The default is ctrl+y+, and thats about two too many keys for my liking.
In sublime I just enter the emmet code and hit tab and it expands it. Is there a way to have it do this vim?
Maybe you should add the line below to your .vimrc:
let g:user_emmet_expandabbr_key = '<Tab>'
:help emmet-customize explains how to customize Emmet's mappings. As a "noob", you owe it to yourself to get used to Vim's documentation.
You could add the line below to ~/.vimr/after/ftplugin/html.vim:
inoremap <buffer> <tab> <plug>(emmet-expand-abbr)
However, Emmet has a lot of features accessible via a number of mappings all using the same "leader", <C-y> so I'm not sure it is a good idea to take the direction you want to take.
I added to my configuration the following mapping
imap ,, <C-y>,
So for example, if I type div or any other emmet expression, then I just type ,, and it gets completed.
i'm using let g:user_emmet_leader_key='<A-e>'
use some special key (<C-e>, <A-e>...) or vim will wait for a emmet-vim command every time you type , or \
These disappear if I do a page-up and page-down. Why does this happen and how do I rectify it?
http://i.stack.imgur.com/DnMYl.png
I recently fiddled around with my vimrc. Could that be the cause?
UPDATE:
I figured out the cause. I had added to functions that automatically updated the cwd name and the current git branch in my vim statusline. This caused vim to be laggy and everytime it lagged on a up/down/left/right key hit, it printed out the ghost characters ^[OA, etc.
It's possible that stuff got complicated because I was using vim in tmux, but I saw the ghost characters outside tmux also. So, probably not.
I've turned off those two functions in my .vimrc and my vim statusline is presently less awesome than it used to be :(
Wish there's a way out.
^[OB and ^[OA are how your terminal represent <down> and <up>.
I've seen these (and their friends ^[OC and ^[OD) appear in the "command line" or omni-completion menus and during usage of a couple of plugins in vim in tmux.
My solution was to map them to the directional keys:
map ^[OA <up>
map ^[OB <down>
map ^[OC <right>
map ^[OD <left>
In case you don't know, you must not type ^[ as two characters, you must do <C-v><Esc>.
That is, while in --INSERT-- mode press the Control key and the V key together then hit the Escape key. Doing so will input the correct single character that looks like ^[.
This issue is discussed at length on the Vim Wiki article. There seem to be multiple causes, I personally encountered this issue when running vim under tmux.
A solution from there that worked for me and seems less hacky than mapping the keys was the following config:
set term=cons25
Hard to say without knowing what's in your vimrc, but you can confirm whether it's something in there by starting it up without running it and seeing if it still happens using the following...
vim -u NONE
Do you happen to be using zsh? I had this issue with vim + zsh/oh-my-zsh. Moving back to vanilla bash solved this issue (amongst others) that I was having with vim.
As a programmer by heart, if not by profession, I increasingly rely on, nay live in VIM for most editing-related tasks. What tips can you offer for using (almost) everyone's favorite editor for editing general-purpose text, say, an article? I mean plain text, with minimal markup using Markdown or RST; I'm not looking for support for LaTeX or for entering mathematical formulae.
I enable soft-wrapping when I'm editing most text files:
:set wrap
If you decide to do the same, then you'll want to know about gj and gk in normal mode, to move by screen lines instead of physical lines. I use them so often I remapped the up and down arrow keys to them instead of k and j.
Whether you're editing hard- or soft-wrapped files, you'll get a lot of mileage out of gqap (or its cousin gwap) to re-wrap a single paragraph with hard newlines, and vipJ to join all the lines of a hard-wrapped paragraph back into a single line.
You might also want to consider including a in formatoptions, to enable automatic paragraph formatting:
:set formatoptions+=a
When you're doing all this wrapping and unwrapping, it's nice to keep Vim from mangling numbered lists:
:set formatoptions+=n
In fact, I'd suggest reviewing all the formatoptions and adjusting them to your particular preferences:
:help fo-table
More info:
:help gj
:help gk
:help gqap
:help auto-format
:help formatoptions
Spell checking:
:setlocal spell spelllang=en_us
" ]s moves to the next mispelled word
" [s moves to the previous mispelled word
Set a thesuarus for Vim
Use par to format text
It's not very well maintained, but the Vim-Outliner project makes Vim into a killer outliner for plain text writing. You can download v0.34 here (there's a more recent version, I think, but I'm not sure where to get it):
http://www.vimoutliner.org/postnuke-phoenix-0.7.2.3/html/modules.php?op=modload&name=Downloads&file=index&req=viewdownload&cid=4
I really enjoyed this blogpost about writing better with latex. You could use vim-latex :) It's more about writing better, than just editing english text though.
http://matt.might.net/articles/shell-scripts-for-passive-voice-weasel-words-duplicates/
Use insert abbreviations:
iabbr teh the
iabbr i I
iabbr definately definitely
Edit, another tip:
set wrap nolist linebreak
This tells vim to wrap lines that are too long with "visual" newlines rather than adding an actual newline character to the file. The 'list' option must be off because it automatically disables the 'linebreak' option.
I want to learn the vim documentation given in the standard help file. But I am stuck on a navigating issue - I just cannot go to the next tag without having to position the cursor manually. I think you would agree that it is more productive to:
go to the next tag with some
keystroke
press Ctrl-] to read corresponding
topic
press Ctrl-o to return
continue reading initial text
PS. while I was writing this question, I tried some ideas on how to resolve this. I found that searching pipe character with /| is pretty close to what I want. But the tag is surrounded with two pipe '|' characters, so it's still not really optimized to use.
Use the :tn and :tp sequences to navigate between tags.
If you want to look for the next tag on the same help page, try this search:
/|.\{-}|
This means to search for:
The character |
Any characters up to the next |, matching as few as possible (that's what \{-} does).
Another character |
This identifies the tags in the VIM help file.
If you want to browse tags occasionally only, without mapping the search string to keyboard,
/|.*|
also does the trick, which is slightly easier to type in than the suggested
/|.\{-}|
For the case, that the "|" signs for the links in the help file are not visible, you can enable them with
:set conceallevel=0
To establish this setting permanently, please refer to Defining the settings for the vim help file
Well, I don't really see the point. When I want to read everything, I simply use <pagedown> (or <c-f> with some terminals)
" .vim/ftplugin/help/navigate.vim
nnoremap <buffer> <tab> /\*\S\+\*/<cr>zt
?
Or do you mean:
nnoremap <buffer> <tab> /\|\zs\S\{-}\|/<cr><c-]>
?
You could simply remap something like:
nmap ^\ /<Bar><Bslash>zs<Bslash>k<Bslash>+<Bar><CR>
where ^\ is entered as (on my keyboard) Ctrl-V Ctrl-#: choose whatever shortcut you want.
This does a single key search for a | followed by one or more keyword characters and then a |. It puts the cursor on the first keyword character. The and bits are there due to the way map works, see
:help :map-special-chars
As an aside, I imagine that ctrl-t would make more sense than ctrl-o as it's a more direct opposite of ctrl-], but it's up to you. Having said that, ctrl-o will allow you to go back to before the search as well.