3

kana/vim-textobj-entire creates text-obejcts ae and ie which stand for the entire buffer. But in lervag/vimtex ae and ie stand for an environment in a .tex file. vimtex's ae and ie mappings are much more useful for .tex files. I wanted to disable kana/vim-textobj-entire for .tex files, so I added the following autocommand to .vimrc

augroup DisableKanaEntireForTeX
    autocmd!
    autocmd Filetype tex let g:loaded_textobj_entire=0
augroup end

but it's not working as expected. Although if I put let g:loaded_textobj_entire=0 it does disable kana/vim-textobj-entire for all filetypes.

How can I disable a plugin's mappings for one filetype?

P.S.- Replacing let g:loaded_textobj_entire=0 with g:textobj_entire_no_default_key_mappings has the same effect.

Improve this question

1 Answer 1

Reset to default
3

UPDATE: Latest vimtex includes PR #1711 which allows you to configure vimtex to override existing mappings by setting this global variable from your vimrc:

let g:vimtex_mappings_override_existing = 1

So the recommended solution for this problem is update your vimtex to latest and include this variable setting in your vimrc.

OLDER UPDATE: It turns out vimtex checks for previously existing mappings, so it will not install one of it mappings if it finds one already exists for that key sequence.

The best workaround I can come up with is that you install these local mappings yourself, for filetype tex. Uninstalling vim-textobj-entire selectively for tex filetype only isn't really possible.

You can add your own mappings by creating a file ~/.vim/after/ftplugin/tex.vim with the following contents:

xmap <silent><nowait><buffer> ie <plug>(vimtex-ie)
xmap <silent><nowait><buffer> ae <plug>(vimtex-ae)
omap <silent><nowait><buffer> ie <plug>(vimtex-ie)
omap <silent><nowait><buffer> ae <plug>(vimtex-ae)

That would ensure these mappings will get loaded for filetype tex, even if vimtex decides to skip them due to the presence of the global mappings for the same key sequences.

ORIGINAL ANSWER (inaccurate): This should not be necessary at all, since the mappings created by vim-textobj-entire are global mappings, while the mappings created by vimtex are local mappings, created for each buffer that triggers the tex (or plaintex etc.) filetype.

Local mappings (created with the <buffer> modifier to :map and related commands) override global ones, so the expected behavior is that the vimtex mappings should already supercede the key-bindings from vim-textobj-entire.

Regarding the part about disabling the plug-in by setting global variables, that only really work in the context of your vimrc, before the plug-in is loaded first.

If you look inside plugin/textobj/entire.vim from that plug-in, you'll see the first few lines are:

if exists('g:loaded_textobj_entire')
  finish
endif

So it's only checking at that point, when the plug-in is first loaded, right after the vimrc is processed. Overriding that variable later won't really have any effect, since by then this plug-in will already have been loaded and will have configured its mappings.

Improve this answer
12
  • I reproduced the behavior described in the question with minimal .vimrc. vimtex-defined ae and ie still not working. If vimtex defines local mappings, I don't know why are they not working.
    – mahbubweb
    May 31, 2020 at 12:29
  • 1
    In a .tex file: With vim-textobj-entire disabled :xmap ie returns x ie @ (vimtex-ie) (same for :omap ie), with vimtex disabled :xmap ie returns x ie (textobj-entire-i) (same for :omap ie). But with both installed :xmap ie returns x ie (textobj-entire-i) (same for :omap ie). In a different type of file: With vim-textobj-entire disabled :xmap ie returns No mapping found (same for :omap ie), with vimtex disabled :xmap ie returns x ie (textobj-entire-i) (same for :omap ie).
    – mahbubweb
    May 31, 2020 at 14:54
  • 1
    @MahbubAlam Yes you're correct! It turns out vimtex checks for existing mappings. I updated my answer, hopefully this will work for you now.
    – filbranden ♦
    May 31, 2020 at 15:04
  • 1
    @kiryph submitted a PR to fix this issue, see here. It is merged and I think it solves the original problem posed in the question.
    – Karl Yngve Lervåg
    May 31, 2020 at 20:48
  • 1
    Update: @filbranden submitted a PR with an option to make vimtex override existing mappings on conflict. let g:vimtex_mappings_override_existing = 1 should now specify to override existing mappings.
    – Karl Yngve Lervåg
    Jun 2, 2020 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.