Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to disable EditorConfig override? #83

Closed
jackielii opened this issue Jun 14, 2022 · 10 comments · May be fixed by #84
Closed

Option to disable EditorConfig override? #83

jackielii opened this issue Jun 14, 2022 · 10 comments · May be fixed by #84

Comments

@jackielii
Copy link

jackielii commented Jun 14, 2022

This feels like an unfortunate situation:

I have a Go project with no modeline or editor config. I use default sw which is 4.

I use LSP go to definition to jump around and end up in something like /opt/homebrew/Cellar/go/1.18.3/libexec/src/fmt/print.go. Then the sw suddenly becomes 2. :verbose Sleuth tells me:

:setlocal expandtab             " from /opt/homebrew/.editorconfig line 8
:setlocal shiftwidth=2          " from /opt/homebrew/.editorconfig line 9
:setlocal fixendofline          " from /opt/homebrew/.editorconfig line 10
:setlocal endofline             " from /opt/homebrew/.editorconfig line 10
:setlocal fileformat=unix       " from /opt/homebrew/.editorconfig line 7
:setlocal fileencoding=utf-8    " from /opt/homebrew/.editorconfig line 6
:setlocal nobomb                " from /opt/homebrew/.editorconfig line 6

To Sleuth, it's definitely working as expected. But not sure I ever want this as everything in my homebrew packages will respect the homebrew's root .editorconfig.

This would normally be fine as I'll never edit these files. But since I have the indent line on, things look very strange. I always have to pause and think if something is wrong.

Maybe an option to disable the EditorConfig? Or exclude folder? The latter feels heavy...

@jackielii
Copy link
Author

Found this undocumented option:

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

@andrewferrier
Copy link

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
Copy link
Owner

tpope commented Jan 6, 2023

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?

@tpope tpope closed this as completed Jan 6, 2023
@gpanders
Copy link

gpanders commented Jan 6, 2023

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

let g:editorconfig = v:false

@andrewferrier
Copy link

@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
Copy link

wickles commented Oct 2, 2023

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
Copy link
Owner

tpope commented Oct 2, 2023

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
Copy link

wickles commented Oct 4, 2023

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
Copy link
Owner

tpope commented Oct 4, 2023

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
Copy link
Owner

tpope commented Oct 4, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants