Hi Soeren,

Thank you for your comments and thank you for caring the open source community.

As stated on the website, "EditorConfig helps maintain consistent coding styles 
for multiple developers working on the same project across various editors and 
IDEs." The focus of the project is to bring developers using different 
toolchains on the same page regarding coding style.

So here is my response:

On 5/3/20 5:19 AM, A Dev wrote:
> Hello, fellow OSS dev here.
> 
> From an outside perspective, I think your project has problems that could be 
> solved but haven't been identified. To me it looks as if you focus your 
> efforts on gaving plug-ins for every possible editor out there. That is 
> important of course but from my point of view, this shouldn't be your 
> priority. The real issues that hinder adoption haven't been tackled, so when 
> the issue of adding an .editorconfig file just came up in our project, I 
> vetoed it. Why?

> 
> 1) The style of outside contributions needs to be checked anyway using tools 
> like clang-format, so I see no real benefit from a project admin's point of 
> view.
> Your web page makes no cost/benefit statements. It just announces that your 
> project exists and what it's for but doesn't give a compelling reason to make 
> use of it. At all. Yet, making use of your project takes time away from other 
> important tasks, so if I consider adoption of your project to be a waste of 
> time, I won't do it.
> 

EditorConfig isn't meant to be a lint tool, but an edit-assisting tool that 
helps developers comply in the first place. That's why you barely see lint 
emphasized but see a lot of editor plugins. Their existence is mostly accessory 
rather than core. If your team is small and your know what your team members 
are using, it is well possible that you don't need EditorConfig.

> 2) There is no easy way to generate an .editorconfig file.
> If the web page had an .editorconfig generator where one could simply pick 
> and choose options, adoption would be higher.
> There's simply no way I'll sit down and manually craft a file to (hopefully) 
> match the existing coding style. If I fail, future contributions are 
> ill-formatted and I have to spend additional time to debug and tweak the 
> .editorconfig file - time that I rather spend on making progress with the 
> project itself.

This is a point that I agree with you. We lack a generator. We used to have an 
effort but I guess it was halted: 
https://github.com/editorconfig/editorconfig-defaults

> 
> 3) There are no templates/presets.
> This is the killer for me. In Eclipse, I can set the C formatter to K&R style 
> and be *done*. clang-formatter has presets [1] to choose from that you then 
> can customize.
> For editorconfig, I have to either start from scratch or copy an existing 
> config from some random project, then understand what it does and adapt it to 
> the project's code. That's just not going to cut it.
> I highly suggest you offer templates on your web page for common coding 
> styles. From my point of view, that is *the* one thing that hinders adoption.
>
I agree that we should have templates. There was the same effort as the 
previous point.

> If you'd combine #2 and #3 by putting presets into a web-based .editorconfig 
> generator (ideally with live preview), this would be perfect.
> 
> I apologize if my comments came off as a little harsh, my intention is to 
> make you understand that these are real issues that shouldn't be overlooked. 
> After all, I do want your project to succeed.
> 

No need to apologize! This is constructive criticism and we should brace it.

Thanks!
Hong

> All the best
>  -Soeren
> 
> 
> [1] 
> https://clang.llvm.org/docs/ClangFormatStyleOptions.html#configurable-format-style-options
> 
> 
> 
> On Monday, August 27, 2012 at 12:32:23 AM UTC+2, Sindre Sorhus wrote:
> 
>     Now that there is a good amount of plugins, more properties and 0.10 just 
> released, I think it's time to talk about how we can get the .editorconfig 
> file out there. We need people talking about it and using it.
> 
> 
>     Some ideas from the top of my head:
> 
>     - The top of the website need to focus more on what kind of problems and 
> pain-points EditorConfig solves. Why should people care? How does it improve 
> their day?
> 
>     - Get the .editorconfig file into more big projects. This creates 
> exposure.
> 
>     - Write an article about EditorConfig and get it published somewhere or 
> convince someone do write about it.
> 
>     - Hopefully it will be included in H5BP: 
> https://github.com/h5bp/html5-boilerplate/pull/1124 
> <https://github.com/h5bp/html5-boilerplate/pull/1124>
>       Any other similar projects we can try?
> 
> 
>     Thoughts?
> 
> 
>     -- 
>     Sindre Sorhus
>     sindresorhus.com <http://sindresorhus.com>
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "EditorConfig" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] 
> <mailto:[email protected]>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/editorconfig/b1fc148b-d751-4141-a63a-f41a8717a044%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/editorconfig/b1fc148b-d751-4141-a63a-f41a8717a044%40googlegroups.com?utm_medium=email&utm_source=footer>.


Hong

-- 
You received this message because you are subscribed to the Google Groups 
"EditorConfig" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/editorconfig/3fad4a89-f851-dd2d-6595-121aeb7f469a%40topbug.net.

Reply via email to