blacklist some ftplugins?

[Marc Chantreux]

Hello people,

I saw there is a write-filetype-plugin section in a documentation and
will read it (and maybe discuss about it) to get something I would like:
ftplugins to provide suggestions instead of setting them (maybe it could
be conventions on how to name the variable that can be the candidate to
setup &mp).

I have no time for this right now and just fixed the problem:

find /usr/share/vim/vim91/ -name sh.vim |
sed 'p;s!/!_!g' |
xargs -n2 mv

That was brutal. was there something less destructive?
for exemple: a way yo blacklist some system filetypes?

filetype plugin user=sh,raku # to say that I take care about those ones
filetype plugin disable=sh,raku # to say I just don't want plugins for those ones

thanks for any help and regards,
--
Marc Chantreux

[Gary Johnson]

How about this? Put this autocommand early in your vimrc, before
any filetype or syntax commands:

autocmd Filetype sh,raku let b:did_ftplugin = 1

Then put this autocommand late in your vimrc, after all filetype and
syntax commands:

autocmd Filetype sh,raku syn clear | unlet! b:current_syntax


I use the following system in my vimrc for controlling which
filetypes get syntax highlighting, but I think the above is
sufficient. (b:syn is used to track the desired state of 'syntax'.
Other autocommands use it to control syntax highlighting when 'diff'
is turned on and off.)

" ":syntax manual" will enable syntax highlighting only for specific
" buffers in which :set syntax=ON" is set. See ":help :syn-manual".
"
syntax manual

let no_syntax_filetypes = [ 'c', 'cpp', 'man', 'netrw', 'objcpp', 'python', 'vim' ]
autocmd FileType * if !empty(expand("<amatch>"))
\ | if !count(no_syntax_filetypes, expand("<amatch>"))
\ | let b:syn="ON"
\ | if !&diff
\ | setlocal syntax=ON
\ | endif
\ | else
\ | syn clear
\ | if exists("b:current_syntax")
\ | unlet b:current_syntax
\ | endif
\ | endif
\ | endif

Regards,
Gary

[D. Ben Knoble]

No such feature exists that I'm aware of, but:

- what is it about sh.vim that you don't like?

- are you aware you can override any ftplugin with either ~/.vim/ftplugin/sh.vim or (usually my preference, when I'm extending rather than replacing) ~/.vim/after/ftplugin/sh.vim? Ditto for syntax and indent, since that's what we ship right now.

See `:help ftplugin-overrule`, `:help 30.3` (indenting), `:help mysyntaxfile` (Yikes, what a documentation mess!)

[Marc Chantreux]

hello,

On Fri, Feb 13, 2026 at 09:10:57AM -0800, D. Ben Knoble wrote:
> No such feature exists that I'm aware of, but:
> - what is it about sh.vim that you don't like?

I often set &mp and &efm manually to have a quickfix mode whatever I'm
doing and it pissed me off multiple times to "magically" lose them then
I realized it happened when I setf or e a shell script so I gave a look at
it and realized that I none of the things done by this plugin has any
value in my workflow so I decided just to delete it instead of fixing
it.

But then I came to another machine and got the same problem and that's
why I asked here.

> - are you aware you can override any ftplugin with either
> ~/.vim/ftplugin/sh.vim or (usually my preference, when I'm extending
> rather than replacing) ~/.vim/after/ftplugin/sh.vim? Ditto for syntax and
> indent, since that's what we ship right now.

I actually had all of my stuff in ~/.config/vim/after and completely forgot
about ~/.config/vim/ftplugin. just moving/touching files to maintain the
blacklist is wonderful. thanks for helping me reactivate my rusted
brain.

> See `:help ftplugin-overrule`, `:help 30.3` (indenting), `:help
> mysyntaxfile` (Yikes, what a documentation mess!)

I'm really impressed by the quality of the documentation given all the
changes that are made in vim from the first version I used (which was
3.something) but yes: sometimes it's hard to find the good part of the
doc.

Thank you so much.

--
Marc Chantreux

[Marc Chantreux]

hello Gary,

thanks for helping but the solution Ben provided is idiomatic and simple
so I will stick with it.

> I use the following system in my vimrc for controlling which
> filetypes get syntax highlighting, but I think the above is
> sufficient.

this is interesting: I'll give a look later on that.

Regards

--
Marc Chantreux