0

I have a plugin/smartcom.vim that I don't want to load for a filetype I have called cheat (for cheatsheets). The smartcom plugin has tab completion that I don't need for my cheat files.

I tried moving the plugin to the /after/plugin directory and added:

let g:loaded_smartcom = 1
let loaded_smartcom = 1

to the ftplugin/cheat.vim file because The smartcom.vim file has this in it:

" If already loaded, we're done...
if exists("loaded_smartcom")
  finish
endif
let loaded_smartcom = 1

I also removed a runtime plugin/smartcom.vim line that was in my .vimrc file.

Despite all this, the plugin still has the tab completion feature. If I remove the plugin totally, cheat files no longer have tab completion so it's definitely this plugin creating the feature.

Is there anything else I can do or try?

Improve this question

1 Answer 1

Reset to default
2

This is not the way things are meant to interact.

Global plugins are by default independent of the current filetype, and always loaded before any ftplugins. Beside, we can alternatively edit files of filetypes {ft1} and {ft2}, there is no way to magically disable and re-enable a global plugin when the filetype changes.

If you want more control, you'd need to fix the global plugin to do nothing for a given filetype. It's not possible to push such modifications on all plugins.

Instead, what you can do, in your case, is may be to add a buffer-local mapping in a cheat ftplugin on <tab> for it to behave as you desire.

Improve this answer
4
  • Well, I rarely change filetypes in the same buffer. So I have a solution, that works for me. I moved the plugin to a directory called ~/.vim/conditional. If a plugin needs it, I put runtime conditional/plugin/smartcom.vim in the ftplugin file. When you say "on <tab>" what does that mean, exactly?
    – StevieD
    Apr 2, 2019 at 16:02
  • The problem is not changing the filetype of the current buffer. It's simply that Vim permits to edit multiple buffers of different filetype. We can jump from one buffer to the other (see :b-commands). We can even display several buffers simultaneously in different windows and jump from one to the other. (I usually have hundred of buffers loaded, up to 20ish windows opened, and having manipulated files of 5-7 different filetypes in a same vim session (C++, python, sh, viml, gitcommit, markdown, qf). When we start to use Vim fully, we cannot alter global settings locally, it doesn't work.
    – Luc Hermitte
    Apr 3, 2019 at 11:09
  • 1
    Regarding <tab>behaviour. Let's say you have a global mapping on tab defined by a plugin you don't control: :imap <tab> @@@. Let's say you don't want <tab> to insert these funny things in your cheat filetype. Then, you can define a cheat ftplugin ({rtp}/ftplugin/cheat/cheat_fixtab.vim) that contains: inoremap <buffer> <tab> <tab> -- the nore part is mandatory to avoid infinite recursion, the <buffer> part is mandatory to restrict the mapping to the current cheat buffer.
    – Luc Hermitte
    Apr 3, 2019 at 11:13
  • Ah ha, I was just wondering what that <buffer> was doing in some places.
    – StevieD
    Apr 3, 2019 at 13:16

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.