Exposure

72 views
Skip to first unread message

Sindre Sorhus

unread,
Aug 26, 2012, 6:32:23 PM8/26/12
to editor...@googlegroups.com
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
  Any other similar projects we can try?


Thoughts?


-- 
Sindre Sorhus
sindresorhus.com

Trey Hunner

unread,
Aug 26, 2012, 7:57:50 PM8/26/12
to editor...@googlegroups.com
On Sun, Aug 26, 2012 at 3:32 PM, Sindre Sorhus <sindre...@gmail.com> 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?

I originally designed the website with the idea that the top should contain a very brief summary of the format and why it's good and then should jump straight into an example that demonstrated the point.  I know that it is not clear enough for everyone to understand how the file format works (make a file and use plugins to read/enforce it) and I'm sure there are other problems of clarity as well.

I have no strong beliefs about what the website should say nor how it should be formatted (it would be nice to make it more beautiful and more legible eventually).  Feel free to suggest a change it copy/style and/or make a pull request to demonstrate your point.

If forking the website, it should be noted that the website currently uses Jekyll and can be tested using "jekyll --pygments --server 9000" to view the website at http://localhost:9000.  We should probably put that information in the README actually and a note that contributions are encouraged.
 
- Get the .editorconfig file into more big projects. This creates exposure.

I think this may be the most important method of garnering exposure (though not necessarily adoption).  I see this file format as very important for JavaScript development and front-end web development in general because the acceptable standards are so fragmented/disputed.  This is why jQuery was the first large project we submitted an .editorconfig file to.

My logic is as follows: good developers often contribute to the tools/frameworks that we all use so if good developers get exposure to this file format and agree that it is a good standard they will spread the word to those that admire them.

 
- Write an article about EditorConfig and get it published somewhere or convince someone do write about it.

I like the "convince someone to write about it" idea.  I think we should strive for more unique explanations of why the format is great.  I've noted many of the reasons I like this format and the reasons I think others should, but hearing this explanation in new words would probably help the cause.
 

- Hopefully it will be included in H5BP: https://github.com/h5bp/html5-boilerplate/pull/1124
  Any other similar projects we can try?



Updating EditorConfig files to add support for some of the new properties would probably increase support as well.  I want to add new properties to the EditorConfig file in chocolatey, but it would be somewhat strange to do so before the Visual Studio plugin supports the new properties.  I also think jQuery and Modernizr could probably benefit from some of the new properties in their .editorconfig files.
 


Thoughts?

I think an important point that you left out is widening the range of editors that support the format.  Creating new plugins ourselves for editors that we don't use probably isn't a great idea at this point because we already have the problem of too many plugins for editors that none of the most active plugin developers use.

Regardless of how these plugins are written (by a user or a non-user of these editors) I think it's very important to support editors with strong communities.

For example I'm fairly sure EditorConfig support in PhpStorm would greatly improve adoption by PHP developers and Eclipse support is absolutely necessary for widespread adoption by Java developers.


Our biggest goal is for text editors and IDEs to natively support for the EditorConfig file format (on by default with an off switch to override).  However, we need to stabilized the basic structure of the format first.  I think issue #71 needs to be resolved before we can focus on this task.
 


-- 
Sindre Sorhus
sindresorhus.com



--
Trey Hunner

Hong Xu

unread,
Aug 26, 2012, 8:43:50 PM8/26/12
to editor...@googlegroups.com
I agree with this. Many of the most popular editors have not been supported yet. Eclipse, I believe, might be the most important one we need to support, since Eclipse is popular in many languages.
>
> Our biggest goal is for text editors and IDEs to natively support for the EditorConfig file format (on by default with an off switch to override). However, we need to stabilized the basic structure of the format first. I think issue #71 needs to be resolved before we can focus on this task.

I don't think #71 must be solved first. In most cases, there are not so many file types. So it would be fine for most projects. But finally we should fix #71.

Hong

Hong Xu

unread,
Aug 26, 2012, 9:02:14 PM8/26/12
to editor...@googlegroups.com
Do you think we should set up a donation system, thus we could hire other people to build the plugin for editors that we seldom use, just like the TextMate plugin?

Hong

Hong Xu

unread,
Sep 16, 2012, 1:47:58 PM9/16/12
to editor...@googlegroups.com
I have more thoughts on this. We have already got 3 blog posts talking about EditorConfig, but they are not really influential: they were posts on personal blogs. Maybe we can try to post on some influential websites?

FYI, Ruby has included an .editorconfig file. (https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/36976) We can be more confident in getting .editorconfig file into more big projects.

Hong

A Dev

unread,
May 3, 2020, 8:19:32 AM5/3/20
to EditorConfig
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.

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.

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.

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.

All the best
 -Soeren


Hong Xu

unread,
Jun 3, 2020, 2:02:51 PM6/3/20
to editor...@googlegroups.com, A Dev
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 editorconfig...@googlegroups.com <mailto:editorconfig...@googlegroups.com>.
> 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

Reply all
Reply to author
Forward
0 new messages