Option to disable EditorConfig override? about vim-sleuth

[jackielii]

Found this undocumented option:

let g:sleuth_editorconfig_overrides = {
    \ expand('$HOMEBREW_PREFIX/.editorconfig'): '',
    \ }

[andrewferrier]

I think there is a related challenge here with NeoVim. @tpope, I'm not sure if you consider NeoVim a supported user of this plugin (although I use and have been using it regularly together over the last few years). NeoVim has fairly recently merged built-in editorconfig support: neovim/neovim#21633. It would be really nice to be able to disable the editorconfig capabilities of vim-sleuth, whilst retaining its heuristics (which are super-useful in the 80% case where editorconfig is not yet used for a project).

[tpope]

Disabling EditorConfig in Sleuth would cause it to apply heuristics even when a relevant EditorConfig rule exists. Depending on autocommand order this could even cause Sleuth's heuristics to override Neovim's built-in EditorConfig support. Whereas now, the worst case scenario is settings get applied twice. Am I missing something?

[gpanders]

@andrewferrier Alternatively, disable Neovim's builtin EditorConfig support in favor of vim-sleuth's (pending neovim/neovim#21649):

let g:editorconfig = v:false

[andrewferrier]

@tpope it's a fair point, current worst case is actually better. Let's stick with what you have.

@gpanders thanks, wasn't aware of that PR.

[wickles]

Found this undocumented option:

let g:sleuth_editorconfig_overrides = {
    \ expand('$HOMEBREW_PREFIX/.editorconfig'): '',
    \ }

I don't think this option supports what I want to do. I want to override editorconfig but only in .git data directories, since I often edit .git/config directly which should always use tabs. Git data directories are not part of the repository so should never be influenced by editorconfig anyway.

[tpope]

I don't think this option supports what I want to do. I want to override editorconfig but only in .git data directories, since I often edit .git/config directly which should always use tabs.

It doesn't do what you want to do, but it solves the problem you're trying to solve. Namely the problem is using *:

[*]
indent_style = space

There's a difference between "this project uses spaces for indentation" and "every file in every subdirectory of this directory should use spaces instead of tabs". Personally, any time I see *, I want to throw the .editorconfig out and start over. Hence the design of the option.

For what you want to do, there's no built-in solution, but it should be straightforward to achieve by sticking a root = true EditorConfig in a Git init template.

Git data directories are not part of the repository so should never be influenced by editorconfig anyway.

Citation needed. I don't see anything in the EditorConfig spec about that. In fact, some usages of EditorConfig assume you do want it to influence .git.

[wickles]

You're right, and I agree about *. Like OP my problem is also related to nested repositories in homebrew. Maybe I will see if I can get this changed over there.

For what you want to do, there's no built-in solution, but it should be straightforward to achieve by sticking a root = true EditorConfig in a Git init template.

Interesting idea! I suppose I can add that to my existing clones as well. Thanks.

[tpope]

I suppose I can add that to my existing clones as well.

If you call git init in an existing repository, it will update the repository with files from the template.

[tpope]

You're right, and I agree about *. Like OP my problem is also related to nested repositories in homebrew. Maybe I will see if I can get this changed over there.

Oh please do. That will help a lot more than just Sleuth users. I think the ideal fix there would be to target not (just?) file extensions but the containing directories. The .gitignore opts in certain paths, and I think the .editorconfig should mirror that, though it doesn't need to be quite so granular.