Skip to content
This repository has been archived by the owner on Aug 21, 2023. It is now read-only.

Wishlist for new property support #5

Open
mnebuerquo opened this issue Sep 5, 2016 · 2 comments
Open

Wishlist for new property support #5

mnebuerquo opened this issue Sep 5, 2016 · 2 comments
Assignees

Comments

@mnebuerquo
Copy link

I like the fact that this bundle just uses vimscript and doesn't require python. I've been using it for my personal editorconfig needs and it's been working well. This issue isn't a bug report, but a vote for new features when anyone has some time to add them.

I recently started working on a project which comes with a more specific editorconfig, and this plugin doesn't recognize some properties the maintainers want to use:

editorconfig: Unsupported property: spaces_around_brackets 
editorconfig: Unsupported property: spaces_around_operators 
editorconfig: Unsupported property: indent_brace_style

I'm having to use a different editorconfig plugin while I'm working on this project so I don't get the warnings every time I open a file, and so I can get the formatting right and not get yelled at when I send a pull request. Adding support for these properties would enable me to use this plugin for my editorconfig for all the projects I work on.

Thanks!

@sgur
Copy link
Owner

sgur commented Sep 9, 2016

"Unsupported property: ... " messages seems useless for me, too.
So I changed the behavior not to display those messages first. 32f1fb1

And your suggested properties such as spaces_around_backets, spaces_around_operators, indent_brace_style looks useful.
I'll support those.

@sgur sgur mentioned this issue Sep 9, 2016
3 tasks
@sgur sgur self-assigned this Sep 9, 2016
@LucHermitte
Copy link

Hi,

I'm just discovering your implementation of editor-config protocol and I've seen this issue.

IMO, the options discussed here cannot be handled only by an editor config-plugin. They need to be used from abbreviations, snippets or anything that triggers code expansion, and code reformatting. This means editor-config plugins will need to provide an API that can then be used by external plugins, or by end-users in their (ft)plugins.

As a mater of fact, I've implemented such API in a dedicated plugin -- the feature used to partially belongs to lh-dev. At this time, only curly_bracket_next_line, indent_brace_style and spaces_around_brackets are "implemented" -- plus other styles from clang-format. Actually, lh-style only provides functions to reformat strings to the chosen style before they're inserted by abbreviations/snippets. The functions are then used by other plugins I'm maintaining, but any other plugin could use them as well.

At this stage, lh-style is able to plug in into editorconfig-vim through dedicated callbacks. To work with your plugin, I'd either need to refactor everything, or provide wrappers that call the right functions if I understand correctly how your plugin works.
Note that if your plugin could support hooks, it'll permit me to inject the following feature.

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

No branches or pull requests

3 participants