Accommodating language-specific rules, config, and scopes

[brettz9]

Hi,

First off, thank you for your work on making this useful tool "just work".

I've run into a couple lesser areas in which it would be nice to have resolution, both related to language-specific features:

1. The focus on file name matching in the .editorconfig spec doesn't seem to be able to take advantage of the Atom-support for multiple scopes within a file (e.g., JavaScript blocks inside Markdown where one may wish for the Markdown to indent by 4 spaces but for the JavaScript code to match the rest of the project with 2 spaces--as I like to do.)

2. While I see there are domain-specific property proposals and this may address some of the use cases for having domain-specific config:

   1. Not every JavaScript-based project is open to having what they see as redundancy in adding an .editorconfig when they already have linting which, at least in theory, should be usable to cover much of the same ground. Even while it is not completely redundant (e.g., eslint will not specify indentation for non-JS files), some projects see things in such a light, depriving those of us who like to work on their projects, but who are not inclined to fork them, to have to make do with the project owner's lack of accommodatability).
   2. ESLint already has very granular language-specific rules which don't seem to be even on the proposal list for .editorconfig. Some projects already expect this in their configs (e.g., config specific to switch indents, IIFE bodies, special handling for ternary operators, and other context-specific handling, as per the eslint indent rule's options.

However, current ESLint-driven tools do not seem to be an adequate solution here--not only due to the limitations that eslint is only for JavaScript, but also because its rule fixers are I believe only suited, per their coding, to apply after-the-fact, and do not set you up for proper indenting when you say hit return and want a newline to already have the indent applied, as with your .editorconfig application (auto-applying fixers might work but I think would come with its own hazard).

While one could develop a tool to query the ESLint config and adjust Atom (to listen for a cursor change, check the scope, and apply the proper indent), to date, the only ESLint-aware tool I am aware of for Atom, eslint-tab-length merely toggles the Atom application-level setting (and it seems to be hard-coded for use with standard).

So I was curious to hear your thoughts on this, as your project is the closest thing I have seen to date; whether in the direction of

1. Adapting your own package to support:
   1. ESLint config file reading (and not merely adding equivalent .editorconfig rules since, again, some projects will, from what I have seen, be inclined to insist on only using ESLint)
   2. Having the ESLint rules apply with scope-awareness (e.g., giving precedence to eslint rules over .editorconfig ones when a nested scope, like JavaScript (source.js) within Markdown, was detected)

OR:

2. To simply allow coordination with other packages that wish to read ESLint configs and apply within a nested scope or at least provide an option to users to disable the application of settings to nested scopes so that other packages could handle the nested scope and/or ESLint config reading.

Thanks!

[Alhadis]

The focus on file name matching in the .editorconfig spec doesn't seem to be able to take advantage of the Atom-support for multiple scopes within a file (e.g., JavaScript blocks inside Markdown where one may wish for the Markdown to indent by 4 spaces but for the JavaScript code to match the rest of the project with 2 spaces--as I like to do.)

See #237. This is a limitation of Atom's APIs, and something that needs to be addressed at the core-level.

Not every JavaScript-based project is open to having what they see as redundancy in adding an .editorconfig when they already have linting which, at least in theory, should be usable to cover much of the same ground. […] some projects see things in such a light, depriving those of us who like to work on their projects

EditorConfig isn't a linter; it's a means to facilitate contributions from people with different coding preferences. I think you'll find projects without .editorconfig files simply lack them because the author is unaware of EditorConfig's existence (or underestimate its importance). Projects that refuse to have an .editorconfig file in their codebase are only damaging people's ability to contribute.

That being said, I don't feel this is enough reason to justify making an exception to the package's current behaviour. Doing so would involve the following complications:

• Adding an additional layer of logic over the underlying editorconfig library powering this package, which could involve any number of complications.
• Justifying the absence of support for other linters and language toolchains; if we give ESLint special treatment, why not markdownlint, stylelint, go fmt, rust fmt, clang-format, and virtually any other specialised tool that reads from a config file?
• Accommodating users who don't want to infer such settings in the absence of an .editorconfig file; do we offer them a package setting to do so? How do we justify the priority with which an .eslintrc file is honoured instead of .editorconfig, or vice versa? What if users wish to alter said priority? Finally, how many projects would actually benefit from this? How many users do you expect would be confused by this behaviour?

All these problems stem from attempting to fix problems that, quite frankly, have nothing to do with this package or EditorConfig, and everything to do with stubborn project-authors not caring about making contributor's lives easier.

ESLint already has very granular language-specific rules which don't seem to be even on the proposal list for .editorconfig. Some projects already expect this in their configs (e.g., config specific to switch indents, IIFE bodies, special handling for ternary operators, and other context-specific handling, as per the eslint indent rule's options.

Atom doesn't provide settings for controlling this sort of behaviour (or only does so in a limited manner). Contextual and language-specific indentation would be a nightmare to implement, and doing so is well beyond this package's responsibilities. Remember that EditorConfig is designed to accommodate all programming languages — when you consider the syntax of more exotic cases like Lisp, Forth, Scheme and PostScript, you'll start to see why granular indentation isn't so straightforward to implement.

In short, I feel the ideas you've proposed would introduce more problems than they'd solve. It would certainly violate the Principle of Least Astonishment, if nothing else.

[sindresorhus]

Closing as Atom is abandoned.