Feature request: Disable for specific filetypes

[lutzky]

My preferences for go (golang) files don't always mesh well with this plugin, which I otherwise really like. See #28 for a concrete example. It could be nice to be able to do something like this:

let g:vim_sleuth_exclude_languages = "go"

[dbarnett]

Does it try to auto-detect settings even when you've explicitly configured them for the filetype?

[tpope]

The idea is that autocmd FileType go set sw=2 should override sleuth.vim. Though it might be possible to break it if you order things weird in your vimrc.

[lutzky]

Okay, more analysis: Vim versions 7.4.488 and 7.4.622 exhibit identical behaviors with the following minimal .vimrc:

set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
Plugin 'gmarik/Vundle.vim'
"Plugin 'tpope/vim-sleuth'
call vundle#end()
filetype plugin indent on
au FileType go set ts=2 sw=2

This form (sleuth disabled) works correctly, with ts=2 and the file described in #28 looking right. When uncommenting line 4 (sleuth enabled), ts=8, ignoring my setting. Moving the filetype lines around the file doesn't seem to have any effect.

[dbarnett]

Yeah, there's no mystery why vim-sleuth overrides your custom settings. It registers an autocmd in plugin/sleuth.vim, after your vimrc executes, so the autocmd will fire late and override other autocmds. The question is whether there's anything vim-sleuth can do to give precedence to other plugins.

If there's nothing automatic, maybe a convention of setting b:options_applied to disable sleuth's detection fallback would work:

au Filetype go set ts=2 sw=2 | let b:options_applied = 1

[tpope]

I could have sworn that I had this working, but you're right, the sleuth autocommand is defined later and will always win over the vimrc.

One thing you could do is stick your overrides in after/plugin/sleuth.vim, or define them from within a VimEnter autocommand.

au VimEnter * au indent_override FileType go set ts=2 sw=2

You could also explicitly runtime! plugin/sleuth.vim before defining your autocommands.

These are all crude hacks, but I think they are better than b:options_applied, which will stick around even if you change file types.

[dbarnett]

I ran into this again and added this to my vimrc as a workaround:

VAMActivate sleuth
" Workaround for https://github.com/tpope/vim-sleuth/issues/29.                
" Define autocmd as early as possible so other autocmds can override.          
runtime! plugin/sleuth.vim

The VimEnter option is much less flexible because it forces you to repeat your explicit configuration values inline. It's not an option if you want to give other filetype plugins control over indent settings instead of hard-coding your own.

I'd really appreciate a fix that could get vim-sleuth to have the right precedence out of the box, though. =)

[ewilliam]

vim-sleuth struggles with mail. takes forever for vim to open within mutt (goes away when i remove plugin), so +1 for exclude ft support

[anntzer]

A similar issue occurs with rst.vim, which uses 3-space indents (see marshallward/vim-restructuredtext#8 for rationale); but if you have item lists à la

- foo bar this is a loooooong
  line
- and so on

then vim-sleuth will set a 2-space indent.

I'm not sure whether the autocommand ordering would make the following work, but perhaps(?) sleuth_automatic could be made a buffer-local variable, so that one could set b:sleuth_automatic to 0 in ~/.vim/ftplugin/foo.vim?

[alecdwm]

This would also be a great workaround for #43

[tpope]

Merged #44 which should provide for this. I also limited it to 20 neighbor files before giving up, which I have a hunch is what was causing the mail slowdown.

[tpope]

I've added options to opt-out of heuristic detection on a per-filetype basis:

let g:sleuth_mail_heuristics = 0

There's also g:sleuth_heuristics to change it from opt-out to opt-in.

This is a bit less flexible than a buffer-local option, but easier to use and not subject to autocommand ordering issues, so I am deprecating b:sleuth_automatic and maybe the global version too, unless someone gives me a good reason not to.