Unmapping filetype mappings

Question

I'm trying to unmap some key sequences mapped by python filetype plugin. While I know a better way, I'm still curious if it can be done with autocommands. Here's what I've got so far:

augroup python_ftplugin
    autocmd!
"\       for m in ['[[', '[]', '[m', '[M', ']]', '][', ']m', ']M']
    autocmd BufNewFile,BufRead *.py
\       for m in ['[[']
\           | if !empty(maparg(m, 'n'))
\               | execute 'nunmap <buffer> ' . m
\               | echom expand('%') . ': unmapped ' . m
\           | else
\               | echom expand('%') . ': not unmapped ' . m
\           | endif
\       | endfor
augroup END

The thing is, when I do :lvimgrep ... *.py, filetype plugin gets executed after my autocommand for the first matched file. Is there a way to remedy this?

Answer 1

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:

1. 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
2. vim-qf <C-Home> and <C-End> (<Home> and <End> for quickfix)
   Pros: no known conflicts with others
   Cons: too much hand movement

3. 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

4. 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.

5. 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)

6. 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