UPDATE 24.3.2019
Vim has updated its Python runtime file $VIMRUNTIME/ftplugin/python.vim in commit 63b74a8 (vim patch should be at least 8.1.1048
) which now respects the variables
g:no_plugin_maps
g:no_python_maps
If you set one of them in your vimrc to 1
, the mappings will not be created.
Unmap via autocmd Filetype python
augroup python_ftplugin
autocmd!
autocmd Filetype python
\ for m in ['[[', '[]', '[m', '[M', ']]', '][', ']m', ']M']
\ | execute('silent! unmap <buffer> '.m)
\ | endfor
augroup END
I have used unmap
instead of nunmap
because there are also xmap
and omap
which you might also want to unmap.
Order of events and when $VIMRUNTIME/ftplugin/python.vim
is sourced
augroup python_ftplugin
autocmd!
autocmd Filetype python echom "Event Filetype python"
autocmd BufNewFile,BufRead *.py echom "Event BufNewFile,BufRead *.py"
augroup END
and add following echom to $VIMRUNTIME/ftplugin/python.vim
:
" Vim filetype plugin file
" Language: python
" ...
echom "Sourcing $VIMRUNTIME/ftplugin/python.vim"
It is very interesting to see that there is a difference between
$ vim myfile.py

:lvimgrep class *.py

Sato Katsura has expressed this as following
Contrary to the popular belief, the order of applying autocmds across multiple files is not well-defined.
Unmap in ~/.vim/after/ftplugin/python.vim
However, if you have many autocommands, filetype is tested for each autocommand, which is not efficient. Furthermore, you replicate something that Vim already does automatically anyway (see the reddit post where_to_put_filetype_specific_stuff by romainl).
Therefore, it is recommended to do this in ~/.vim/after/ftplugin/python.vim
for m in ['[[', '[]', '[m', '[M', ']]', '][', ']m', ']M']
execute('silent! unmap <buffer> '.m)
endfor
Add variable to $VIMRUNTIME/ftplugin/python.vim
to disable mappings
Update This section is outdated; upstream has incorporated this.
Actually, $VIMRUNTIME/ftplugin/python.vim
should follow the recommendation given in
:h write-filetype-plugin
The user must have a chance to disable the mappings in a filetype
plugin, without disabling everything. Here is an example of how this
is done for a plugin for the mail filetype: >
" Add mappings, unless the user didn't want this.
if !exists("no_plugin_maps") && !exists("no_mail_maps")
" Quote text by inserting "> "
if !hasmapto('<Plug>MailQuote')
vmap <buffer> <LocalLeader>q <Plug>MailQuote
nmap <buffer> <LocalLeader>q <Plug>MailQuote
endif
vnoremap <buffer> <Plug>MailQuote :s/^/> /<CR>
nnoremap <buffer> <Plug>MailQuote :.,$s/^/> /<CR>
endif
If you can convince the current maintainer (https://github.com/tpict/vim-ftplugin-python) to make the mappings optional, you only have to place let no_python_maps = 1
to your vimrc.
Do you really need the builtin [[,[],]],][,[m,[M,]m,]M
for python?
I would highly appreciate if you could add a python code snippet to your question illustrating where you want to use the builtin motions. Otherwise I consider your question unmotivated. Do you know the motions [{
and ]}
?
For an illustration what the mappings of the filetype plugin python do, see here End of python block motion. IMHO they are very useful not only for python.
Update: Convenient Cycling Through Quickfix/Location List
As it has turned out the OP is using [
and ]
to cycle through the location list. As I said in the comments I would not advice to use them for this because they are namespace keys similar to z
and g
.
Suggested alternatives:
- vim-unimpaired
[l
and ]l
([q
and ]q
for quickfix) (maybe with repmo-vim)
Pros: no known conflicts with others
Cons: too much weak finger movement and keys
- vim-qf
<C-Home>
and <C-End>
(<Home>
and <End>
for quickfix)
Pros: no known conflicts with others
Cons: too much hand movement
http://vim.wikia.com/wiki/Short_mappings_for_common_tasks#Quickfix (function key)
Pros: common scheme (e.g. F3
in PyCharm & F4
in Sublime Text) and less conflicts
Cons: too much hand movement
ale-inspired
nmap <silent> <C-k> :lprevious<CR>
nmap <silent> <C-j> :lnext<CR>
Pros: home row keys (in particular when capslock is remapped to ctrl)
Cons: already used by others (e.g. ale, switch between splits, vim-tmux-navigator/pilot, edgemotion)
vim-syntastic does not dare to suggest any specific mapping (except mentioning vim-unimpaired) but certainly sees a motivation for this.
Leader to space plus j/k
(or n/p
)
let mapleader = "\<space>"
nnoremap <leader>j :lnext<CR>
nnoremap <leader>k :lprevious<CR>
Pros: space bar by strongest finger and jk are home row keys
Cons: possibly already used but others are also available (e.g. ln/lp
)
macOS:
- MacVim:
<Ctrl-Cmd-Left/Right>
for quickfix (default)
<Alt-Cmd-Left/Right>
for location list (add to gvimrc)
- Xcode-inspired:
<Ctrl-Cmd-G>/<Ctrl-Shift-Cmd-G>
Find next/previous in workspace
lvim
is – D. Ben Knoble♦ Dec 9 '18 at 2:27BufNewFile,BufRead
is not enough or wrong in this case. I saw the other question where there's a hint (not only hint now) at solving my X (of XY) problem. But from what I can see now, I most likely used the wrong events.FileType
event is most likely to be used in this case. I'm also interested in why in this particular case filetype plugin executed afterBufRead
, but the answer probably: "That's just the way it works." – x-yuri Dec 9 '18 at 14:18:lvimgrep
. See details in my answer. – Hotschke Dec 10 '18 at 8:55