Consider defining a `b:` variable to indicate settings were loaded from config

[dbarnett]

Would it be possible to define a variable in each buffer where editorconfig triggered to indicate that settings were explicitly configured, something like b:has_explicit_editorconfig = 1?

The reason is that if formatting settings are known good from an explicit config, it would be useful to propagate those out to other systems like https://google/vim-codefmt, but vim also has a lot of wonky defaults and heuristics from things like https://github.com/tpope/vim-sleuth that shouldn't be treated as "canonical" and exported out to other tools. Something like that could check if exists('b:has_explicit_editorconfig') and then know it wasn't overriding a reasonable default with a garbage value from vim.

[cxw42]

Sounds reasonable to me - PRs welcome :) . I note that EC may configure different settings in different projects depending on the specific EC files. Could you flesh out this idea with a bit more detail about how your desired plugin behaviour would reflect that (if at all)?

[dbarnett]

Some context at https://github.com/google/vim-codefmt/pull/136#issuecomment-580315891.

What I had in mind is that if there's any .editorconfig for the project, the buffer gets this signal to indicate some thought has been put into the style settings, and then vim-codefmt will automatically pay attention to the buffer's shiftwidth etc. when it invokes the formatter. A few scenarios: 1) .editorconfig sets sw=2, and vim should configured indent_width=2 when invoking the formatter. 2) .editorconfig and another config like .style.yapf have discrepant settings. Slightly better for the other formatter config to win. 3) vim-sleuth sets or vim defaults pick weird style settings. Formatter should ignore current vim settings and rely on its own notion of the right defaults or selections from outside vim. 4) User sets style settings manually in vim buffer, then wants those to be inherited by the formatter tool. They could manually define variables like these, or have some other explicit signal in codefmt for requesting tools inherit vim's relevant settings.

[dbarnett]

Hmm, on second thought brokering all the config settings through vim may not be a great approach (although it may still be worthwhile having a signal to know editorconfig is active).

I'd been thinking about having the config flow like .editorconfig -> vim -> formatter but now that I think about it people don't always run the formatters through vim and should ideally get the same formatting behavior whether they invoke a formatter inside vim or outside, so preferably the configuration would be more like .editorconfig -> vim .editorconfig -> formatter

For instance, if I have an editorconfig with [*.py] indent_size = 2 and I run yapf -i somefile.py on the cli, that should not rewrite the file with 4-space indents. It's going to be an uphill battle to get all the different formatter maintainers to read .editorconfig, but that'd be the best approach.

[dbarnett]

Tangent from this issue, but I posted google/yapf#826 to support editorconfig (and I see they have a .editorconfig file for their own code, so maybe there's hope🤞).

I could imagine most tools won't want to take on the complexity, and it might be helpful to have a small cli tool or library that could take a file path and dump a flat listing of settings to use for that path.

EDIT: Nevermind the part about providing a library. I see now that's exactly what you've done in the core libraries at https://editorconfig.org/#create-a-plugin!

[cxw42]

@dbarnett .editorconfig->formatter is definitely a topic of discussion - see, e.g., links in editorconfig/editorconfig#415. Given your https://github.com/editorconfig/editorconfig-vim/issues/141#issuecomment-599851837 , is this issue still one you're interested in pursusing at this time?

[dbarnett]

Sure, it's less of a priority for the particular issue I was running into but it's worth having some kind of signal, like vim's conventions of defining loaded{PLUGINNAME} and b:did_load_ftplugin.

Mailed you #142 to define "invoked" and "had_config" variables. The latter is a little more nuanced (e.g., should it be true if there was a file but no matching rules?), but the straightforward behavior of "was there an applicable editorconfig file?" should be a decent general-purpose check to support.

[cxw42]

@dbarnett Thanks - I'll take a look! So you're not surprised, responses may be a bit delayed due to coronavirus-related schedule adjustments :/ .

[dbarnett]

Same here, just didn't want to leave this discussion unresolved.