EDITORCONFIG environmental variable for global config

[Jorengarenar]

The topic was raised on multiple occasions, but I do agree, there wasn't a sufficient reason provided.

The problem

Assume you are, for various reasons, using multiple code editors (e.g. Vim, Notepad++ and VS Code), on different machines.

In such case, if you want to change your default settings for one language or want to add setting for a new one, you need to edit multiple configs.

It's irritating on its own already, but undoubtedly one will once forgot to do it for one editor, what will cause minor, but nevertheless problems.

Solution

Some universal config... like EditorConfig. It is already de factor standard solution for such problem, the only thing missing is ability to point to global .editorconfig file of lowest priority.

Hence my proposition: EDITORCONFIG environmental variable.
If it's set to valid file (responsibility of user), plugins will always read (even if root=true in project) the file pointed by it first, then apply settings given by more specific files (like in the root of project).
If not set? Simply ignore.

Making it to behave similar to PATH variable is also something worth consideration as it won't add much more overhead and could be useful (perhaps it would be some solution to #236).

Response to counterarguments

I've already read other issues, so I'll respond (or quote/paraphrase) to already provided alternatives and counterarguments against such feature

~/.editorconfig

Issue of polluting $HOME aside, yes, it does work most of the time (breaks when there's root=true).

But it isn't system wide solution, only works for files kept under home.
That's a problem, since I often work e.g. under /media directory.

Another benefit of variable over file in home is that variable can be easily disabled (EDITORCONFIG= editor ...), while file needs to be moved and later restored.

Variables are also usually good compromise for users striving for XDG Base Dir compliance without going into the rabbit hole of what to do under different systems.

Use hard links

It lack the convenience of global file and would effectively block creation of project specific .editorconfig

Copy "globals" as base for .editorconfig for each project

Not a bad idea, but what about project-less files? Like configs or quick temporary scripts?

EditorConfig is for multi-developer projects

It's the initial idea, yes. But making it an aide for single developer with multiple codebases wont hurt the cause, only enrich the project.

If developers can point to a repository full of company-blessed configurations for every language (whether it is stored in their home folder, an adjacent repo, or even a submodule of the project), the code produced throughout the organization would look consistent regardless of what repository it's in, or who worked on it. ~ @masaeedu

Global editorconfig is a dangerous thing to do. especially if you're contributing to lot of different projects, because doing so would enforce your local settings, which may malform the current project.

But I'm already doing that. Those are already set in editor settings, because nobody is creating new project for every secluded file.

Global .editorconfig ought to be of the lowest priority. Then the only difference it makes is the convenience for the user - instead of setting those in multiple configs for multiple editors, only in one universal, standardized file.

Related

• Generalize config lookup mechanism #408
• XDG compliance #461
• Allow specification of default settings #227
• Default EditorConfig File #298
• Feature request: extending external configs #236
• Include .editorconfig from other folder #456
• Presets? #245
• Support Importing .editorconfig files #436
• Feature Request: Merge several .editorconfig files on the same directory level #462
• Custom location for .editorconfig editorconfig-vim#172
• Doesn't Respect ~/.editorconfig editorconfig-vim#54
• Global fallback .editorconfig editorconfig-emacs#203
• Create a global .editorconfig sindresorhus/atom-editorconfig#14
• Set a default .editorconfig. sindresorhus/atom-editorconfig#137
• fix(configfile): use user's editorconfig file if not found in dir tree editorconfig-vim#88

---

I hope this time we will work out a satisfying solution 😉

[cxw42]

Thanks for the consolidated list of related issues. That is very helpful!

[Jorengarenar]

So, any thoughts?

[cxw42]

an aide for single developer with multiple codebases

To support this use case, I would propose reading the files in the other order:

1. Read .editorconfig files as currently.
2. If you do not stop at a root=true file, read and process the single file named in $EDITORCONFIG.
   • If you do stop at root=true, ignore $EDITORCONFIG.

That way, any project with its own .editorconfig files can set root=true at the top and not have to worry about personal settings creeping in.

[cxw42]

root=true

Or, alternatively, the rule could be that if no .editorconfig files are found in the regular search, then (and only then) $EDITORCONFIG is checked. That would unambiguously preserve the current behaviour for projects using EditorConfig, while supporting the use case of an individual dev creating multiple repos and not wanting to copy .editorconfig into each repo.

[Jorengarenar]

Fine for me.

Although I was thinking about the reverse: first read $EDITORCONFIG then override it via .editorconfig files, because we want to go from the general to the specific (i.e. "I usually indent with spaces, but for this project I want tabs").
^{I forgot that EditorConfig first checks for root=true recursively up the tree, then goes down and applies the setting.}

I wonder if always reading $EDITORCONFIG (as "parent" of root=true too) wouldn't be a better idea?
Behaviour then would be no different than users settings their "defaults" in each editor they use (except now they could do it in one common file).
But again, either way is fine.

not have to worry about personal settings creeping in.

We have this problem currently; or even worse, because not only do personal setting creep in, but also unchanged defaults from the editors (which aren't always the best).

[florianb]

How about adding the $EDITORCONFIG_ROOT_FILE (i would like to advocate a more specific variable name as well) referenced config as a topmost config?

This would maintain backwards compatibility for projects or settings maintaining a inheriting config setup and allow maintaining custom defaults?

[Jorengarenar]

@florianb Isn't it essentially the same what I proposed?

[florianb]

@Jorengarenar you're right - i should have written the second paragraph in a different way.

I support your proposal - but i would like to put the variable name up for a discussion since it could be misleading what "EDITORCONFIG" in the contexts - where one faces it - means.

I also think it's a good idea since

• it requires an explicit user action to make it happen (in opposite to repo provided file system references)
• it will enable a good bunch of requested use cases

[florianb]

And as for single developers with multiple code bases this is just a way to start with a (inherited) config for file types.

A editorconfig tool should then suggest to make these rules explicit (by taking them over into the projects definition) but you won't have the game anymore to start a project by collecting the rules you might need based on a file type expectation.

[cxw42]

@florianb Just checking --- are you supporting the "parent of root=true" proposal? Read all the way up to / or root=true, and then read $EDITORCONFIG_PERSONAL_DEFAULTS (or whatever we call it)?

I personally think root=true should still stop the search as the spec currently says:

The search shall stop if an EditorConfig file is found with the root key set to true in the preamble

That reduces the risk of accidentally changing files during the transition period when not all cores/plugins support $EDITORCONFIG_PERSONAL_DEFAULTS. Once that transition period is over, we can see what use cases people are still having trouble with. What say you?

[florianb]

@cxw42 thank you for asking 🙏 - i'm a bit confused. Let me try to recap it in my words:

Issue

1. You'd like to use defaults over file not being maintained in a EditorConfig tree (as filed by @Jorengarenar).
2. You'd like to use centrally managed defaults f.e. required by the corp.

Proposal (as i understood it)

Introducing $EDITORCONFIG_DEFAULTS would become the root even for project files with root=true

This would change:

1. The behavior of the * rules: if a "default" was be defined for a file-type which isn't explicitly covered by another rule, the rule of the "default" would be applied rather than the * rule from the local .ediorconfig (lets call this local-asterisk conflict)
2. Uncovered file-types: any file without a parenting EditorConfig file or which is not covered by a local rule would have the defaults applied

Counterarguments

1. A developer would expect the root=true being the root level of rules

One could argument this shouldn't be an issue since the dev has to actively introduce the env variable referencing to the EditorConfig to apply.

2. A developer could forget about having an env variable set which now messes all further projects with a wide usage of * up.

I spend some thoughts on this issue and i don't see a good strategy to avoid this.

My conclusion

Given i recapped everything right i guess i slightly changed my mind. In the former comments i think i underestimated the effect on asterisk-based rules.

The point is if a global config drains in with a specific rule for let's say yaml files defining an indentation size of 4 instead of 2 - this would mess up working with the default requiring either to remove the referencing env var for that project, removing the explicit yaml rule from the default or creating an explicit rule for yaml files in the project.

When i concluded this right i'd prefer to have a env variable acting as "root" file above / and not changing the behavior of root=true. For group projects root=true gives a promise about the applied settings for all participants.

If you're working on your own you might want to omit the use of local EditorConfigs at all and rely on your "global" referenced EditorConfig.

Does this make sense?

[Jorengarenar]

Let's consider an example:

You work on a C++ project. As it is a well maintained repository, it does specify root=true in the root of the repository.
There are no settings for Python in the .editorconfig as it's C++ project. You want to write a temporary Python helper.
You write the file in editor abc on WSL, which for Python sets* tab to be expanded as 4 spaces.
Late evening you want to make a quick edit to said helper, but since WSL as of last update launches forever, you just pull out editor xyz on Windows. But! xyz for Python doesn't expand tab! Only displays as 4 space width.
Now we have a tab in space indented Python file. You get frustrated by something what shouldn't occur in the first place.

That's the current state of matter. Proposition of $EDITORCONFIG_DEFAULTS aims to solve i.a. such situations, but as you may notice, if root=true prevents it from working, the problem still remains.

$EDITORCONFIG_DEFAULTS is more in relation with config files of text editors, rather than .editorconfig files.

^{* doesn't really matter whether it's from program's defaults or from some config file}

[cxw42]

i'd prefer to have a env variable acting as "root" file above / and not changing the behavior of root=true. For group projects root=true gives a promise about the applied settings for all participants.

@florianb This sounds reasonable to me!

[cxw42]

@Jorengarenar

config files of text editors, rather than .editorconfig files.

I think this is the heart of the matter. EditorConfig's purpose is to prevent having to look at whitespace in diffs :D . (More specifically, to "maintain consistent coding styles for multiple developers working on the same project" per https://editorconfig.org.) A particular editor's default configuration is outside the scope of EditorConfig.

In the example you give (Py file in a C++ project), I would do two things. I'll use Vim as my example because that's what I know :) .

1. Create ~/.vim/ftplugin/python with set ts=4 sts=4 sw=4 et ai. That will set the defaults for any Python file I edit to four-space indents.
2. Open a PR adding a *.py rule to the project's root .editorconfig!

Configuring an editor using an editorconfig-format file

If I understand you correctly, you want to set your default per-filetype editor settings using editorconfig-format files rather than your editor's native configuration language. I think a plugin could implement that if you wanted. As long as the behaviour of the plugin is unchanged for files that match rules in .editorconfig files, I don't see any harm in the plugin supporting optional defaults.

[Jorengarenar]

A particular editor's default configuration is outside the scope of EditorConfig.

Not one particular editor - I want to have one common default config for every editor I use.

Create ~/.vim/ftplugin/python with set ts=4 sts=4 sw=4 et ai. That will set the defaults for any Python file I edit to four-space indents.

That handles abc on WSL; what about xyz on Windows?
The solution isn't setting the same in "xyzRC" as that's precisely what I want to avoid.

Open a PR adding a *.py rule to the project's root .editorconfig!

Should I try forcing my personal preferences on three teams of people or engage them into pointless meetings to agree upon style for a language which probably will never be into the repo? And should I repeat this for every such project?

If I understand you correctly, you want to set your default per-filetype editor settings using editorconfig-format files rather than your editor's native configuration language.

I want to have the same setting *regardless of which editor I open the file with, without needing to synchronize multiple configurations for that. If I want to change the exemplary tab size, I want to edit one file instead of five.

I think a plugin could implement that if you wanted.

I can send a PR with this feature for editorconfig/editorconfig-vim even today, but who will do the same for plugins for other editors I use? And at this point, wouldn't it be easier to just standardize it anyway?

[xuhdev]

I agree with @cxw42 that the proposal to use one .editorconfig file for a user's preference for all editors is out of scope. The project scope is defined in first sentence in editorconfig.org:

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

Since adding the environmental variable that skips root=true conflicts with the project's primary objective, I won't support adding it. (Note that a plugin is free to do whatever that does not conflict with the spec. If you merely need a non-conflicting feature, it doesn't have to be in the spec and you can request the specific plugin project to implement it.)

Having said this, if you would like a spec that manages one configuration file that is automatically recognized by multiple editors on your system, I would say it's better to propose a new project. It can be more powerful, such as by compiling the single source of configuration to the configuration file of each editor on your system. But I personally doubt the effort would be worthy for such a project -- the overwhelming majority of people stick to at most 2 or 3 editors, which often intentionally need to diverge on their configuration. In the worst case, a manual sync won't be too difficult.

[Jorengarenar]

BigProject
├── build
│   └── deps
│       ├── foo.d
│       └── bar.d
├── .editorconfig
├── Makefile
├── subprojects
│   └── parallel_project
│       ├── build
│       ├── .editorconfig
│       ├── Makefile
│       ├── lib.c
│       └── lib.h
└── src
    ├── foo.c
    ├── foo.h
    ├── bar.c
    └── bar.h

If setting root=true makes plugin ignore the env variable, how to make ParallelProject use $EDITORCONFIG_DEFAULTS without using BigProject's .editorconfig`?

[florianb]

If you're working in a project having a "root" EditorConfig the creator of this config claims that this EditorConfig-File should be authoritative. If this EditorConfig misses any configuration of a new file i would consider adding properties for that file or removing the root-property.

[Jorengarenar]

How about two environment variables?
It covers both use-cases, doesn't really require more work to implement, is pretty clear what effect it has and the user will need to make an explicit choice of using the second variable.

environment variable	description
EDITORCONFIG_DEFAULTS	List of EditorConfig-files separated by : (analogous to $PATH) If set, plugin will read those files as the top-most EditorConfig-files in case of no root file
EDITORCONFIG_SUPERROOT	List of EditorConfig-files separated by : (analogous to $PATH) If set, plugin will always read those files as parent of root/$EDITORCONFIG_DEFAULTS files

[cxw42]

in a project having a "root" EditorConfig the creator of this config claims that this EditorConfig-File should be authoritative

I agree with this. Overriding a root=true project's settings defeats the purpose of editorconfig.

I do not support the SUPERROOT idea.

[Jorengarenar]

I agree with this. Overriding a root=true project's settings defeats the purpose of editorconfig.

The settings set in root=true file still ought to take precedence over the $EDITORCONFIG_SUPERROOT.
The variable would be for things which are not defined in the root file.

[Jorengarenar]

$EDITORCONFIG_SUPERROOT:

[Makefile]
indent_style = tab

[*.py]
indent_style = space
indent_size = 4

[*.c]
indent_size = 4

[*.rb]
indent_style = tab

project/.editorconfig:

root=true

[*.c]
indent_style = space
indent_size = 8

[*.rb]
indent_size = 2
indent_style = space

project/subdir/.editorconfig:

[*.c]
indent_size = 4

[*.py]
indent_style = tab

project/extern/.editorconfig:

root=true

[*.c]
indent_style = tab
indent_size = 2

[*.rb]
indent_size = 5

Result:

filetype	path	style	size
Python	~/toy.py	space	4
C	~/gra.c		4
Ruby	~/wee.rb	tab
Makefile	project/Makefile	tab
C	project/foo/bar.c	space	8
Ruby	project/foo/xyz.rb	space	2
C	project/subdir/one.c	space	4
Python	project/subdir/test.py	tab	4
Makefile	project/extern/Makefile	tab
C	project/extern/file.c	tab	2
Ruby	project/extern/wat.rb	tab	5

[Jorengarenar]

Currently the it looks like this:

• ~/.vimrc
  • project/.editorconfig
    • project/subdir/.editorconfig
  • project/extern/.editorconfig

.vimrc is already ignoring the root=true!

With the variables:

• ~/.vimrc
  • $EDITORCONFIG_SUPERROOT
    • project/.editorconfig
      • project/subdir/.editorconfig
    • project/extern/.editorconfig

For the root=true-EditorConfig-file there is no change in behaviour whatsoever if there is an env variable or there isn't.

[florianb]

I feel like you'd like to "optimize" how to specify EditorConfig settings. I take one example, the project/extern/.editorconfig and the tab versus space definition.

Given the assumption this is a module of code standing alone you really should duplicate the indent_style setting here! Having a SUPERRROOT would be exactly the same as having root=false - you would have to rely on the assumption every collaborator has the same "surrounding" to the project as yourself.

And since this is not possible the root-setting was introduced. Duplicating the settings seem to be not efficient but it is the only way to standardize the editor behaviour between collaborators.

If you introduce new files to a shared repository where the setting is wrong you should (in my opinion) aim for a fix of the config file - that's the way to negotiate that setting with the other collaborators. One shopuldn't override the settings for a repository, because it would cause a lot of troubles for all other collaborators - this iss the point about EC in general, isn't it?

[cxw42]

As far as I can tell, this idea (from above) is one the team can support:

i'd prefer to have a env variable acting as "root" file above / and not changing the behavior of root=true.

@Jorengarenar is this of any value to you? If not, I do think @xuhdev's point about having your own project for editor defaults (as opposed to project settings) is worth considering, particularly given the effort you've put into this proposal!

@xuhdev @florianb If this idea (root above /) is not of value to the requester, I suggest we close this issue as not planned.

[Jorengarenar]

Well, it's still a vast improvement over having a file in home directory, so even if unnecessarily limited, there is still value there.

 

having your own project for editor defaults (as opposed to project settings) is worth considering

My point was that EC is an ideal candidate for that already (down to the name).
I don't really see the point of doing essentially the same just under different name from zero.

[xuhdev]

@Jorengarenar I don't see how EditorConfig is an ideal candidate. You are proposing to have a central place to save a configuration for all editors you use. As a matter of fact, as I said before:

the overwhelming majority of people stick to at most 2 or 3 editors, which often intentionally need to diverge on their configuration.

This is already pretty straightforward to maintain if you maintain your own dotfiles. There isn't really much incentive to add significant complexity to EditorConfig for something that's already easy and clean to achieve.

[Jorengarenar]

I don't see how EditorConfig is an ideal candidate

Because most editors have EC plugins which are capable of setting the settings? As I wrote at the very beginning:
Some universal config... like EditorConfig! It is already de facto standard solution for such problem, the only thing missing is ability to point to global .editorconfig file of lowest priority.

There isn't really much incentive to add significant complexity to EditorConfig

Pseudocode:

defaults := getenv("EDITORCONFIG_DEFAULTS")
IF defaults THEN
    FOR file IN defaults DO
        FilesToParse.push(file)

That's essentially all I needed in editorconfig-vim.
The example wording for specification itself is also just few short sentences.

You are proposing to have a central place to save a configuration for all editors you use

I by no means am proposing to have the editors be fully configurable from EC, just the settings which are already supported.

I really, really, really:

• don't want to have to click through dumb menus or JSON files to edit VS Code tab width or other basic setting
  (one change in $EDITORCONFIG_DEFAULTS and I have it set for both Vim, VS Code or another editor of the year)
• don't want to have to maintain in my dotfiles configs for multiple editors I don't even like
  (having WSL's settings.json here was already PITA enough, VS Code is only worse in that regard)
• have one place where I can override all those basic from my personal settings with corporate ones

---

P.S. @florianb

you would have to rely on the assumption every collaborator has the same "surrounding" to the project as yourself.

I don't need to assume - if it's singular (even automatable) action, in corpororate environment it's doable to set everyone
(on the other hand, having everyone manually create a file for each project? Teaching lama to drive would be easier).

In case of open-source, nothing changes from current state as EC-defaults sit alongside vimrc/setting.json/... in mental model.

[florianb]

I really, really, really:

* don't want to have to click through dumb menus or JSON files to edit VS Code tab width or other basic setting
  (one change in `$EDITORCONFIG_DEFAULTS` and I have it set for both Vim, VS Code or another editor of the year)

* don't want to have to maintain in my dotfiles configs for multiple editors I don't even like
  (having WSL's settings.json here was already PITA enough, VS Code is only worse in that regard)

* have one place where I can override all those basic from my personal settings with corporate ones

I am sorry, i do not understand that argument:

One is supposed to define one EditorConfig per repository.

It is the responsibility of the repo maintainer to assure a proper EditorConfig exists.

If one creates ten repositories per day and therefore needs to create dozens of EditorConfigs one might use a project template.

The current EditorConfig approach aims to direct all effort devs might have with editor configuration to the single moment where a technology get's introduced (aka where the repository is initialized).

(edit: Also i haven't seen the requirement of having different EditorConfigs per different Editor-technologies.)

Given we try to change the "root"-rule behavior this will introduce a lot of pain because it will negate the fundamental assumption the creator of the root EditorConfig made: that her rules of whitespace handling apply.
And i am completely sure it won't take much of time (whatever we assume about the usage of this property) when whitespace misfits drain into the repositories of the world and we face exactly the same chaos what lead to the introduction of the EditorConfig.

edit: reconsidering after the 2 new comments

I would like to close this issue for now since i can't see how that fundamental conflict could be resolved.

xuhdev - i am not allowed to close issues. I ask for your help.

[Jorengarenar]

Given we try to change the "root"-rule behavior this will introduce a lot of pain because it will negate the fundamental assumption the creator of the root EditorConfig made: that her rules of whitespace handling apply.

Again: anything set in file root=true applies as it's more specific than $EDITORCONFIG_DEFAULTS

There is virtually no change to how EditorConfig behaves currently.

What changes is essentially an addition of reuse the already established mechanism to provide a solution for configuring defaults

[ffes]

To me this request is quite straight forward.

When there is a root=true in a .editorconfig, we're done and everything behaves as it does at the moment. No changes there. As @florianb mentions, very important indeed.

When you open an editor in a directory that doesn't have a .editorconfig file and $EDITORCONFIG (or whatever it is called) is set it will use the settings in that file.

Nothing more, nothing less. And as long as that is the behavior, it's fine with me and I might probably use it.

As @xuhdev mentions when you only have one pc with a couple of editors, there is not much added value to this feature. But when you have 3 computers (like me: home win pc, home linux laptop, work win laptop, both windows using native git bash and wsl2) with multiple editor (VS, VSCode, N++, vim) it seems a useful feature.

[Jorengarenar]

OK, let's just go only with $EDITORCONFIG_DEFAULTS for now and leave $EDITORCONFIG_SUPERROOT for eventual consideration in the future if there's demand.

[cxw42]

@xuhdev Sounds like we are ready for a vote on the proposal, as summarized by @ffes , with proposed env var name $EDITORCONFIG_DEFAULTS. Does it seem that way to you as well?

[Jorengarenar]

So... did the voting take place?

[cxw42]

Not as far as I know. @xuhdev ?

[xuhdev]

I don't think so. You are free to start voting.

However, I personally disagree with the global config idea.

What are the new scope of EditorConfig?

Approving this feature request is not about a new feature -- it's a scope change of EditorConfig.

It deviates from the objective of the project. The structure of the project does not bear in mind with personal settings across multiple editors or machines. Moving forward would open the step to enlarge the scope -- what would you change the mission statement "EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs" to? What are the future guideline to create new features?

Implementation issue of environmental variable

If we decide to implement the environment variable proposal, the most elegant implementation brings structural changes to our core libraries -- this is no longer just adding a property; all core libraries must change their behavior and be careful with the consistency of this behavior. The spec is designed in a way that the core libraries should be modified at a minimal level with new features added, because changing core libraries are expensive and have many dependent editor plugins.

My proposal to OP's issue

To me, the easiest solution -- if you would like to reuse anything that EditorConfig has defined -- is to create a compiler that compiles .editorconfig files to editor settings. It would be an EditorConfig dependent and won't affect EditorConfig itself.

[xuhdev]

Responding to OP's argument of "EditorConfig is for multi-developer projects"

Every project has a scope, because a scopeless project is also useless. Stated in the above, this scope is stated in the first sentence in the spec and is an integral part of it. The spec should be read as a whole. Adding an unrelated feature would require changing this statement.

Despite the quotation, nothing in your "The Problem" section state the problem in relation to the company-blessed configuration idea. If we are interested in support the idea of company-blessed configuration, we should discuss the issue in that context, not in the context of synchronizing settings between multiple editors and machines of a single person.

However, if you believe the scope of the project should be enlarged, it can be discussed but it must be well defined. The argument shouldn't be something like "this feature is useful". Hacking in a feature and call the scope "current scope + this feature" is not a good argument IMO.

EDITORCONFIG_DEFAULTS does not conflict with the project objective. Should we give it a shot?

If it doesn't conflict with or serve the project objective, then it shouldn't become part of the spec. Instead, it is OK to create a document that recommends some optional "courtesy" features. The core library or the editor plugins can choose to implement on a courtesy basis, but not necessary, and can be overridden by future spec changes. However, please also keep in mind that every such side feature would hurt future flexibility in changing the spec if we are to preserve them.

What is standing between the proposed EDITORCONFIG_DEFAULT feature and the current spec?

There's still a minor confict -- we don't officially state in the spec that root = true should be set for every project. If we state that, I don't see a conflict between EDITORCONFIG_DEFAULT and the spec. I would be OK with creating a document recommending the proposed EDITORCONFIG_DEFAULT feature.

[cxw42]

@xuhdev

root=true

we don't officially state in the spec that root = true should be set for every project

Interesting point --- that had not occurred to me. It is true that if someone doesn't set root=true at the top of the project, EC will not be nearly as useful for that project 😆 .

We could, e.g., add a "Best current practices" section to the spec with tips like "always set root=true in the top .editorconfig".

optional features

document that recommends some optional "courtesy" features.

I would recommend we not have such a document. It seems to me an invitation to Hyrum's Law issues. I agree with your point that "every such side feature would hurt future flexibility." At least if the spec is silent on a feature, we can evaluate a change only with respect to the spec and not also with respect to all possible combinations of optional features.