Doesn't respect /.editorconfig

[divVerent]

On systems where I also need to edit files outside my home a lot, I made /.editorconfig a symlink to my homedir's .editorconfig file.

This, however, does not work because of this line in autoload/editorconfig_core/ini.vim:

let l:config_dirname = fnamemodify(a:config_filename, ':p:h') . '/'

The reason is that for /.editorconfig, this produces //.

Changing it to only append the slash if there is none already fixes it:

let l:config_dirname = fnamemodify(a:config_filename, ':p:h:s?/*$?/?')

Not sure if that's the greatest solution, but it definitely is one that works.

[cxw42]

This seems very related to editorconfig/editorconfig#465 . Until a decision is made on that issue, this could be implemented as a plug-in option. However, core behaviour has to be unchanged when that option is not set.

I personally think handling this use case via the above-linked issue would be best, so I suggest you voice your support in that issue.

[divVerent]

I strongly disagree that this has to wait for the $EDITORCONFIG proposal.

This is a clear bug as it differs from the editorconfig command line utility, which does interpret the /.editorconfig system wide file already (note that I was not talking about ~/.editorconfig or maybe a hypothetical /etc/editorconfig).

The reason why I absolutely need it is that at my company /companyname is a global mountpoint and I can't place an .editorconfig file in there (and even if I could, that's basically a network share so such a file would apply to all employees, not just me) - and all our sources I edit are within that directory. Placing a file in /.editorconfig works fine with the editorconfig tool, but not this vim extension - that's basically my problem. I could mount the same thing also elsewhere and place an .editorconfig file along the way, however that'd break lots of existing tooling that generates the "standard" paths with the "standard" mountpoint.

[divVerent]

And it's actually more funny - editorconfig-vim does read the /.editorconfig file and parses global options from there, but it does NOT match any [**/companyname/**] or similar sections, because while building the match expression it generates a regex that only matches paths starting with // - which no normalized unix path does. The editorconfig utility does not have this issue.

[cxw42]

Oh, it wasn't clear to me this was a report of existing behaviour different from editorconfig-core-c. Thanks for the additional detail!

[divVerent]

As for implementation, I am really not happy about the :s?/*$?/? line noise... but could not find a much cleaner way to do this in vim script.

I wonder if there really is no builtin function to put a / at the end of a path if there is none yet. Or maybe the better way is to not use :h but instead just replace away the .editorconfig at the end?