I have an odd problem with mapping in Vim. I am using an Azerty keyboard.
In my .vimrc, I have the following command to quickly move between paragraphs.:
nnoremap _ {
vnoremap _ {
nnoremap è }
vnoremap è }
However, the second mapping using è is not taken into account.
After startup, if I check the mapping, I got something for :verbose map _ but nothing for :verbose map è.
Worse, if I actually type nnoremap è }in runtime, the mapping is correctly registered.
I think this is an encoding issue, but I don't manage to find a work around.
I am using Vim 7.3 on Debian Lenny.
I am using the same .vimrc on WinXP, and it works there : the only difference is that on WinXP I am using set encoding=latin1 beforehand, while on Debian, I have not changed the default encoding which is utf-8
So basically, my question becomes why it works with encoding equals to latin1 and not utf-8 Does it have something to do with è being encoded in multiple bytes in utf-8 ?
Perhaps the .vimrc file encoding is not correct.
You can see it using set fileencoding, and change it using :w ++enc=utf-8 or :w ++enc=iso-8859-1.
Related
I use rxvt-unicode terminal emulator on Manjaro, and the following two mappings in my .vimrc don't work,
nnoremap <C-PageUp> :tabprevious<CR>
nnoremap <C-PageDown> :tabnext<CR>
even though the following does work
nnoremap <C-t> :tabnew<CR>
I think the reason for the behavior you observe is exactly the one described here.
In other words, something like this (what the rhs is doesn't matter)
nnoremap <C-PageUp> :echo "hello"<CR>
will not work as Vim does not now which escape sequence corresponds to the keycode <C-PageUp>.
Therefore, you can provide it with the escape sequence corresponding to Ctrl-PageUp, as in
nnoremap ^[[5^ :echo "hello"<CR>
where the first two characters of the escape sequence, ^[, are part of a single unit that corresponds to Escape (that's why escape seqeunce).
You can get the whole sequence (which could be different from mine in your terminal, by the way) from insert mode by hitting
Ctrl+VCtrl+PageUp; however, given the meaning of ^[, you can also use Ctrl+VEscape and then type [5^ manually.
Unfortunately, putting set <C-PageUp>=^[[5^ causes error E518. I don't know why.
On the other hand, another solution is the following (again described here)
set <F37>=^[[5^
nnoremap <F37> :echo "ciao"<CR>
where <F37> is one of the extra function keycode Vim provides. I have no clue where this thing is in the :help.
I have added set term=xterm to my vimrc to be able to use 256-color vim schemes in terminal, but it comes at a price (at least for me). It also replaces (sort of) the BackSpace with Delete (i.e. BackSpace starts to delete forward just like Delete does) in insert mode and makes it "BackSpace" instead of moving left (or h) in normal mode. I have nothing against Ctrl-H as a way "to Backspace", but I simply don't want to have two delete buttons and ability "to BackSpace" (delete backward) in normal mode.
How can I reverse that change while retaining the setting I need?
PS I've read :h CTRL-h and a bit of :h xterm, but I couldn't find the solution.
Vim's inoremap and nnoremap commands can be used to adjust how keys are interpreted in Vim.
A solution is documented here for your specific context: https://conemu.github.io/en/VimXterm.html
The relevant quote:
"If you have problems with BS in Vim (BS acts like Delete key) under ConEmu when term=xterm, you may try to remap BS key:
inoremap <Char-0x07F> <BS>
nnoremap <Char-0x07F> <BS>
"
In general, when a key does not do what you want, the trick is to find out what it actually sends to Vim. Sometimes hitting Ctrl-V followed by that key in insert mode might help figure it out. Then inoremap and nnoremap as shown above can be used to reassign it to the behaviour you want in insert and normal modes, respectively.
The problem
I have a Scandinavian keyboard, and I want to bind my Æ, Ø and Å keys. For example, I use Ø as leader:
" ok, works:
let mapleader = "ø"
When the .vimrc is encoded in latin1, this works like a charm. However, I want to use :set enc=utf8 in my .vimrc, and then the mappings stop working:
" whoops, doesn't work:
let mapleader = "ø"
set encoding=utf-8
I presume this is because the .vimrc is written as utf-8, and that Vim is unable to parse or map the multi-byte characters.
What I want is to be able to use my non-ascii keymappings while still defaulting to utf-8 for all files other than .vimrc. (Storing .vimrc as latin1 would be an acceptable solution, but I haven't figured out a way to do it.)
Approaches that don't work
I have tried all kinds of things, and none of the following work:
Modelines that set encoding and/or fileencoding for .vimrc.
Mapping the keys to "\u00f8" and similar values instead.
Putting non-valid utf-8 sequences in .vimrc to force defaulting to latin1.
Various autocommands to set encoding and/or fileencoding for .vimrc.
Opening Vim with --cmd "set encoding=latin1", because I edit my .vimrc too frequently for that to be feasible.
How can I use both set encoding=utf-8 and map my non-ascii keys?
The problem is caused by the ultisnips plugin. Disabling ultisnips will resolve the issue.
I have mapped Ctrl-j to move to the buffer below. However it was hard mapped
to something else so I had to write the first row below to make it mappable at
all.
The script below works perfectly, except when I write .sh files. I have
bash-support plugin installed.
let g:C_Ctrl_j = 'off'
map <C-j> <C-w>j
EDIT: I have just found out that the problem is in bash-support. Bash-support
maps Ctrl-j to jump insert (or something like that) which moves cursor at a
predefined point and goes to insert mode. I guess changing that in bash-support
script will do the job though I don't like messing with those files.
EDIT2: let g:C_Ctrl_j = 'off' actually turns the csupport plugin jump insert feature.
According to the document of bash-support.vim:
The original meaning of Ctrl-j is 'move [n] lines downward' (see |CTRL-j|).
If you are accustomed to use the default and don't like these jump targets you
can switch them off. Put the following line in the file '.vimrc' :
let g:BASH_Ctrl_j = 'off'
So that you have to put let g:BASH_Ctrl_j = 'off' into your vimrc.
Additionally, use nnoremap <C-j> <C-w>j instead of map <C-j> <C-w>j in your vimrc.
The latter defines key mappings in Normal, Visual and Operator-pending modes.
The key mappings are also recursively expanded.
It might cause troubles when you define more key mappings.
Ctrl-j (0x0A) is a special character, Line Feed.
There's a good chance that this key-press is not is not arriving at Vim as Ctrl-j (0x0A).
In Vim in a Terminal.app window on my Mac, typing Ctrl-v Ctrl-j displays ^#, (0x00 or NULL). Whereas Ctrl-v Ctrl-g and Ctrl-v Ctrl-k display ^G and ^K, respectively.
I'd suggest using another mapping (or just training yourself to use Ctrl-w j).
I had the same issue, but for a different reason. VIM-LaTeX uses imaps.vim plugin, which also remaps some keys, including Ctrl-j. What worked for me is to set an autocmd in my .vimrc:
augroup vimrc
au!
au VimEnter * unmap <C-j>
au VimEnter * noremap <C-j> <C-w>j
augroup END
The VimEnter trigger makes sure that the remap will executed after vim starts up, and the plug-ins are loaded (if I understand it correctly), so it overwrites the imaps.vim plug-in's maps. The unmap isn't necessary, but it can't hurt.
Try non recursive mappings,
nnoremap <C-j> <C-w>j
ought to do it.
In order to edit html files, I have the following three imaps in a file that I source for filetype html:
imap <buffer> <M-[> ü
imap <buffer> <M-;> ö
imap <buffer> <M-'> ä
This works fine until I change the encoding of the html file with set enc=utf-8. Now, pressing Alt-[ for example gives me a Û.
Interestingly, after sourcing the same file again, it expands the imaps correctly.
This doesn't really make sense to me. So, why is this and how can I have a more constistent environment regarding imap and utf-8.
This is occuring with gVim 7.1 for Windows.
It sounds like the same problem listed here: https://superuser.com/questions/154491/utf-8-option-makes-alt-key-to-insert-accented-characters-in-vim-how-to-disable-i
I'd suggest putting set encoding = utf-8 in your vimrc above your imap mappings, rather than turning it on for specific files.