search

editorconfig / editorconfig-vim

EditorConfig plugin for Vim
http://editorconfig.org
Other
3.13k stars 137 forks source link

Let hooks know which config file every property from #170

Open thawk opened 3 years ago

thawk commented 3 years ago

I want to implement c_include_path property from my hook. Since I don't know the exactly directory everybody checkouts the project, so the path in .editorconfig can only be relative paths. And since editorconfig may be nested, the relative path should be relative to the exactily .editorconfig file which defines the property. By now, we can only get property value of c_include_path, can translates it into absolute path. So I think it's neccesary to let the hooks know which file the property is defined.

cxw42 commented 3 years ago

We can report that information, but it would be a big change. Also, the paths would not take symlinks into account because of Vim limitations.

What are you using the property for? Maybe there is a different way to solve your problem. An EditorConfig plug-in hook is not always the best choice.

thawk commented 3 years ago

I want to implement the c_include_path property for C/C++ files. In a large project, there're tens of modules, and tens of paths to search header files in. I want to:

  1. Add those include paths into buffer local &path, so I can easily use gf to open header files.
  2. Other plugins can also using these paths, e.g. LSP or clang related plugins can add those paths to its compile parameters to do syntax check and more helpful jobs

Because some modules can be reused in difference project, placed into difference directory, it's better to config c_include_path in module specified .editorconfig file. So it's not enough to know the location of root .editorconfig file. c_include_path is a language specified property, and not a standard property, I don't know whether it's suitable to put in plugin. I think we can have an API to use the property name to lookup .editorconfig file path should be enough to implement it with hook, and it doesn't break the old API. It's better if we have more common way to solve the problem, as I'm wondering maybe similar property is need for other language.