Since upgrading from Ubuntu 18 to 20, I'm finding out that some of my vim mappings are not working while others are unaffected.
My mapping to toggle spell checking is among those mappings affected:
map <F5> :setlocal spell! spelllang=en_us<CR> :hi SpellBad cterm=underline,bold ctermfg=red ctermbg=DarkYellow <CR>
Am I missing something? Thank you in advance.
Related
I found vimrc key remapping of / in vim-better-default plugin and added to my config.
The remapping works as expected, but this remap also causes an issue with jump using the relative number. For example, when I run 5<CR>, I need to type enter once more for it to work and it only jumps for 4 lines. The output in the bottom display is :.,.+4
I tried adding these but it did not work either.
autocmd CmdwinEnter * nnoremap <CR> <CR>
autocmd BufReadPost quickfix nnoremap <CR> <CR>
Thanks,
I tried spell check for text file by adding this to my vimrc
augroup set_spell
autocmd!
autocmd FileType text :setlocal spell spelllang=en_us
augroup END
nnoremap <F10> :setlocal spell! spelllang=en_us<CR>
And it did not work
I tried :set spell and nothing happened
For some reasons, when I ran :source $MYVIMRC (still in that window), it worked. Though I can add sourcing command to my vimrc but I don't like the glitchy feeling of it.
What am I supposed to do?
Edit: I have found the solution
It's the problem with this vim rainbow plugin
https://github.com/frazrepo/vim-rainbow
So I uninstall that one and install this instead https://github.com/luochen1990/rainbow
Open the file and immediately do a :set ft? and :set spell?. Make sure they return text and spell respectively. If text is not returned, then the filetype is not being detected. If text is returned but spell is not, then the autocommand is not working.
Additionally, you should wrap autcommands in an augroup. See :h autocmd-groups. It might look like this:
augroup set_spell
autocmd!
autocmd FileType text setlocal spell
augroup END
Because this is a FileType autocommand, you are probably better off skipping the augroup and autocommands altogether and just putting the line setlocal spell in an ftplugin file. It would normally go in ~/vim/ftplugin/text.vim.
As a more general solution: Sometimes theme plugins overwrite SpellBad highlight group(It's one those gui vs terminal problems). Even though spell check works it just doesn't highlight. Without deleting your theme you can just add more style to the SpellBad highlight group as you wish:
Simply add this to your .vimrc:
"underline spell errors in terminals
hi SpellBad cterm=underline
or any other style really:
hi SpellBad ctermfg=Cyan cterm=bold
Be warned, these do not overwrite all existing styles. To truly overwriting it you may need to use hi clear SpellBad first.
See :h highlight for all the details. For the other Spell groups see :h hl-SpellBad.
I am trying to map the '-' key to move a line down
in my vimrc I have
noremap - :m .+1 <cr>
but the carriage return is ignored and displayed in the terminal as <cr>
After reading Vim ignores <cr> i tried adding an additional <cr> but that just echoes the characters twice.
So after pressing the '-' key I have to physically press the <enter> key to get the command to run.
I have tried this in mac and linux and get the same results.
It works if I set nocp.
I haven't come across any instructions that this must be set for <cr> to work.
So this is the issue.
set nocp is set if a vimrc is detected.
if you are testing a custom vimrc and starting vim with vim -u mycustomvimrc then despite the fact it is loading a vimrc file it does not set nocp and maintains backward compatibility. In such cases you need to set nocp explicitly.
Thanks for all the suggestions to get this resolved.
I recently started using vim-makegreen with mvim.
The issue is that the red/green bars do not work with mvim. They do work with mvim -v (or otherwise console vim).
After further investigation it appears that the highlight groups that are defined as:
hi GreenBar term=reverse ctermfg=white ctermbg=green guifg=white guibg=green
hi RedBar term=reverse ctermfg=white ctermbg=red guifg=white guibg=red
within makegreen.vim are cleared by mvim just prior to calling the .gvimrc file. After mvim has started I get:
:hi RedBar
RedBar xxx cleared
:hi GreenBar
GreenBar xxx cleared
Does anyone have any insights into why mvim is clobbering highlight groups? The only work around that I have found thus far is to redefine them again inside .gvimrc. But this is clearly a pain. Trying to figure out if I am missing something here.
Update
I just stripped down my .vimrc and using pathogen I only place makegreen in bundle dir. The result is the same behavior.
My .vimrc has only one line:
call pathogen#infect()
The bundle directory only contains makegreen bundle. The autoload directory only has the pathogen.vim. I removed .gvimrc.
I then start mvim and execute :hi RedBar and get the same result as above. I used an echo statement to confirm that makegreen.vim is being sourced.
I installed mvim with brew install macvim. The version of macvim is 7.3(64) and I am on OSX Lion.
Update 2
I just took it a step further and removed the reliance on pathogen. Now I only have makegreen.vim in plugin directory and an empty .vimrc file. Same result.
Add let macvim_skip_colorscheme=1 to your ~/.vimrc. See the comment before the colorscheme is loaded in your global gvimrc:
" Load the MacVim color scheme. This can be disabled by loading another color
" scheme with the :colorscheme command, or by adding the line
" let macvim_skip_colorscheme=1
" to ~/.vimrc.
if !exists("macvim_skip_colorscheme") && !exists("colors_name")
colorscheme macvim
endif
All color schemes clear the highlights.
I had the same problem.
The workaround was to redefine GreenBar and RedBar in ~/.vimrc (or python.vim, etc.)
When I use the arrow keys in vim in insert mode I get letters inserted instead of movement.
Up produces an A
Down produces a B
Left products a D
Right produces a C
Does anyone know what would cause this?
Thanks in advance
If these keys work fine in normal mode, but do not in insert then you must have some mappings to the first one or two characters (normally <Up> is either <Esc>[A (terminals that use CSI) or <Esc>OA (xterm)). Try checking out output of
verbose imap <Esc>
, there should be not much mappings starting with <Esc> in insert mode (I have none, for example). I can say, that with arrow keys working normally in insert mode, using
inoremap <Esc> <Esc>
produces just the same behavior as if you had problems with terminal recognition or had 'compatible' set.
Your vim seems to be starting in the vi compatibility mode. Do this
Open Vim editor,
Get the path of your home directory by typing :echo $HOME
Check if you have .vimrc file in $HOME location,(if you don't have create it)
Add the following line line to .vimrc file
:set nocompatible
Find more solutions for the same problem here ( Especially if your problem is terminal related, the re-mapping of keys solution might work for you )
The following worked for me. Just put it in your .vimrc
:set term=cons25
Open Vim editor.
Get the path of your home directory by typing: :echo $HOME.
Check if you have .vimrc file in $HOME location, and if you don't have create it.
Add the following line line to .vimrc file: :set nocompatible
Reference: http://vim.wikia.com/wiki/Fix_arrow_keys_that_display_A_B_C_D_on_remote_shell
None of the answer here worked for me. I'm in Linux, with konsole/yakuake terminal and tmux. This fix works for me:
nnoremap <silent> <ESC>OA <ESC>ki
nnoremap <silent> <ESC>OB <ESC>ji
nnoremap <silent> <ESC>OC <ESC>hi
nnoremap <silent> <ESC>OD <ESC>li
inoremap <silent> <ESC>OA <ESC>ki
inoremap <silent> <ESC>OB <ESC>ji
inoremap <silent> <ESC>OC <ESC>hi
inoremap <silent> <ESC>OD <ESC>li