Spec implicit assumption about the nature of the implementation is not fully accurate

[mipo256]

This issue inspired from the following discussion:

Currently, the spec defines the following components:

In EditorConfig:

- "EditorConfig files" (named ``.editorconfig`` in lowercase) include
  section(s) storing key-value pairs. EditorConfig files must conform to this
  specification.
- "Cores" parse files conforming to this specification, and provide
  key-value pairs to plugins.
- "Plugins" receive key-value pairs from cores and update an editor's
  settings based on the key-value pairs.
- "Editors" permit editing files, and use plugins to update settings for
  files being edited.

These definitions basically make an assumption, that the EditorConfig specification is here mainly for text editors and IDEs:

"Editors" permit editing files, and use plugins to update settings for
files being edited.

While that is true that editors tend to support .editorconfig files and the spec in general, the problem is that the editorconfig is not always implemented by plugins in the IDE. For instance, there are Maven/Gradle plugins and other pieces of software that implement EditorConfig spec but they are not used to edit the text and do not relate to text editors whatsoever. They are a part of build/CI process.

Those CI/build plugins basiaclly used during build to either ensure that given file "X" confirms to the restrictions defined in the spec, or to (literally) change the content of the given file "X" during the build to make it confirm to the spec.

The problem is that the current version of the spec, and the max_line_length as it is being discussed makes an assumption that it is supported by so called "Editors", i.e. IDE/text editor components, which is not the only case.

Proposal:

I am not sure if we should make any assumptions about the nature of tool that is implementing the spec. Current spec does that assumption, and becuase of this the definitions like max_line_length tend to reflect that assumption in themselves.

[cxw42]

I don't think the term "editor" needs to change, but I would be fine with something like

"Editors" check or modify files, and use plugins to update settings for those checks or modifications. "Editors" may be interactive text editors, autoformatters, or other types of tools.

Farther down in the spec we already say

Some editors include or bundle plugin or core functionality

That would be the case for autoformatters, for example.

(Note: as with many other issues, this one relates to editorconfig/editorconfig#415)

[mipo256]

Hey @cxw42, thanks for sharing your opinion.

Farther down in the spec we already say

Some editors include or bundle plugin or core functionality

It is not clear to me how this part relates to the topic raised in the current issue. We have the definition of the editor:

"Editors" permit editing files, and use plugins to update settings for files being edited.

And this lines cleraly, IMVHO, contains the assumption about the implementation.

I don't think the term "editor" needs to change, but I would be fine with something like

"Editors" check or modify files, and use plugins to update settings for those checks or modifications. "Editors" may be interactive text editors, autoformatters, or other types of tools.

Yeah, I want to be clear, I do not really want to remove the notion of "Editor". Let me clarify my intent: I want to make sure, that the spec does not make assumptions about what the implementation currently look like. I gave an example in the issue that this assumption is not entirely correct. The problem of such "assumptions" is that they affect the design, like in the max_line_length case.

I hope my concern is clear 😄