Add a standard configuration to every contributor follow

[brunoocasali]

Context

When I delivering some pull requests like #648 and #647 I've noticed about my editor not removing trailing spaces to me, then I realized this project have no standard configuration about editor configuration. So, this PR addresses this improvement!

Summary of Changes

• Added editorconfig

[DeeDeeG]

Quick comment: We are looking at adopting the Rubocop linter for Ruby code in #644. Hopefully this is consistent with what Rubocop does? (For example: the amount of spacing for indentation).

[brunoocasali]

Quick comment: We are looking at adopting the Rubocop linter for Ruby code in #644. Hopefully this is consistent with what Rubocop does? (For example: the amount of spacing for indentation).

Yes @DeeDeeG, rubocop and editorconfig can live in the same project! Actually editorconfig can prevent many offenses that will be raised by rubocop :)

[DeeDeeG]

@brunoocasali do you mind if this is the config?

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

I think it's simpler to apply the rules to all files. And it looks like the markdown/md rule may have been auto-generated, but I personally think it's a good idea to add a newline at the end of markdown files.

I have tried this configuration in Atom, with the editorconfig package. It seems to work fine with all our existing files.

[DeeDeeG]

If you agree with applying these rules to all files, this comment allows applying the change with one button press. Feel free to ignore this if you rather update it on command-line. And I'm completely open to discussion/your thoughts on which rules should apply to which files.

Suggested change

	root = true
	[*]
	insert_final_newline = true
	trim_trailing_whitespace = true
	[*.{rb,yml}]
	indent_style = space
	indent_size = 2
	end_of_line = lf
	charset = utf-8
	[*.{md,markdown}]
	trim_trailing_whitespace = false
	root = true
	[*]
	indent_style = space
	indent_size = 2
	end_of_line = lf
	charset = utf-8
	trim_trailing_whitespace = true
	insert_final_newline = true

Best regards,

- DeeDeeG

[brunoocasali]

Yeah, this Github feature is awesome!

I'm just concerned about the markdown files, because markdown uses trailing spaces to deal with line breaking and other rendering stuff.
And I agree with u about making it more simpler, (less is more!).

[brunoocasali]

What about:

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.{md,markdown}]
trim_trailing_whitespace = false

[DeeDeeG]

Thank you for bringing that to my attention. I am surprised to hear that trailing whitespace can be meaningful in MarkDown files.

That having been said, the three MarkDown files in this repository (CODE_OF_CONDUCT.md CONTRIBUTING.md, and README.md) currently do not use trailing whitespace to mean anything (I think our MarkDown files do not have any trailing whitespace at all?), and I personally prefer that no trailing whitespace should be used in any files, even in MarkDown files.

If EditorConfig can make that happen, then that's great.

[brunoocasali]

@DeeDeeG by default, two spaces in markdown is the same as a <br>, so even if our files don't use that today doesn't mean that never will be used 😅 (to me keeping that config is a "future proof", that prevents someone have some trouble with this)

Having said, if you still prefer to remove trailing spaces by editorconfig let me know and I will change 🥇

[DeeDeeG]

Alright, I think this is ready to merge, then.

If you want my thoughts on trailing spaces, you can read on. I didn't want to seem arbitrary by not explaining my views. But ultimately these comments are not needed to be addressed. They are just my thoughts.

---

I greatly prefer:

• Start a new paragraph <p> HTML element, by typing two newlines, AND/OR
• Transition to a new kind of content, whether it be a header, paragraph text, or a code block

Very distant second place:

• Indicate a line break with <br> or a trailing \
  • (potentially formats new lines within the same paragraph)

Very, very distant third place (please, folks, don't do this):

• Indicate a line break with two or more trailing spaces
  • (potentially formats new lines within the same paragraph)

---

We have been using either new paragraphs (indicated with two newlines), or else a transition to a new type of content (header to paragraph text, paragraph text to a code block) to induce line formatting. This has been adequate for our formatting needs, and is both intuitive to read, and in my opinion unambiguous/not confusing for the reader. Simple is good.

This also makes the spacing of the document more uniform, and hopefully easier to skim. The situations where a newline is needed, within the same paragraph as previous lines of text, are rare, and so far we have not needed this.

And MarkDown handles these newlines within a paragraph in a way that isn't great:

• Even intentional trailing spaces could be ambiguous in their intent vs a typo accidentally included in the file. This makes a pull request a bit harder to review, and is a source of potential friction in the review communication process. ("Was this a typo? Can you use <br> instead?")
• <br> elements look awkward, and in my opinion it's ideal not to use <>-style HTML elements in MarkDown, if it can be avoided.
• Trailing slashes \ are not intuitive or similar to any other formatting characters I've seen in other languages. In the command-line, trailing slashes nullify the meaning of newlines, not preserve them. The choice doesn't make much sense to me. This should also be avoided, in my opinion.

(Ideally, single newline characters such as LF should have been respected, not ignored. They should have been treated as literal newlines in formatting the document. This is how newlines are interpreted in GitHub comments, and it makes sense to me.)

That said, it is a valid part of the language to use two trailing spaces to indicate a newline. So just in the interest of not confusing people who are used to that, I suppose trailing spaces should be allowed...

It would have been my preference for trailing whitespace not to be a meaningful part of the language. I personally hope contributors will not use it. I'm not the only maintainer here, though, and the other maintainers have not commented yet, so I'll allow it.