should we track editor files in version control?

[ashleygwilliams]

in exploring this repo, i've realized there are a large number of editor specific configuration files. i found this a bit surprising, and personally feel it has cluttered the repo.

in general, i do not personally include editor files in a open source repo, unless:

• a team has a standardized IDE setup that they expect external contributors to use
• the files are of use for multiple editors (e.g. an .editorconfig)
• the files can be kept to a single location in the repo, that is clearly documented (even this i am not a huge fan of)

the motivation for this general practice is that clutter in a repo is a type of cost. when making tradeoffs, i tend to preference beginners and new contributors as they are the the folks with the highest needs and least capability. IDE configuration files are often for seasoned contributors and advanced users, who have the least need and the highest capability. beginners will rarely complain that their IDE is not customized, though they can be overwhelmed by editor specific files - wondering if they are part of the project and if they need to understand them as well.

i would love to hear more about why this team chose to include editor specific files in this repo! thanks

[Enrico2]

I definitely understand the sentiment of having too many config files, such that external contributors might not be familiar with and may seem overwhelming. That clutter is real.

Personally, in the past year I've encountered more and more repositories that include their .idea or .vscode folder checked in, and as an IntelliJ user, I found that to be tremendously helpful to get things up and running quickly. I've really appreciated those repositories setting me up for success like that.

IntelliJ unfortunately does require some set up for "things to look good" -- meaning, if I open a .rs file which depends on some 3rd party or even another crate in the workspace, IJ has to know about that relationship, defined in its own config, for code to not show up as "red", have code completion, etc. It has to know that the .rs file I'm looking at is part what it defines as a "Rust module" to know to even use cargo/rustc to compile, apply the Rust plugin, etc.

When checking in editor specific files, it's been my philosophy to do it only if they create added value for the editor's users, and do not affect other users (including by not cluttering the repo).

That got me looking into what we have checked in, and regardless of the outcome of the issue, I've done some cleanups for files that we don't use at all, and moved all Idea specific files into the .idea folder without affecting functionality (#87).
That PR at least minimizes the clutter and centralizes everything Idea related to .idea.

If we end up deciding here that we want to remove all of these files, it will just mean adding .idea to .gitignore.

Generally, the value of checking in these files (as opposed to .gitignoreing them) is mainly around situations in which the module structure changes:

1. Checking out/switching between branches that have different modules/dependencies.
2. Cloning the repo from scratch.

In those situations, the editor quickly reverting to the "good setup" makes for quick productivity when context switching. If .idea is ignored, the module set up is lost when switching branches and requires the developer to manually do it every time. This ends up resulting in cloning the repo multiple times to avoid the added hassle.

Having said all that, I don't think we should ever expect all contributors to use any specific editor, nor do we expect the entire team to do so, but if we can ease the lives of those who do, without significantly affecting the lives of those who don't, I consider that a worthy trade off.

I hope you'll consider the 3rd option you've suggested as a good compromise, and if so, I'll make sure we document the existence of the .idea folder appropriately.

[Enrico2]

Any more thoughts on this? (doing some issue housekeeping)