Clarify behavior of trim_trailing_whitespace

[ffes]

One of the things that need to be clarified is how trim_trailing_whitespace = true is expected to work.

At the moment almost all implementations I use trim all the trailing whitespaces that exist in a file on save. IMHO that is the expected behavior.

The native Visual Studio implementation only trims whitespaces when enter is pressed at the end of a line. That seems fairly odd and unexpected behavior to me, but "it works as designed" they say: https://developercommunity.visualstudio.com/content/problem/134457/editorconfig-trim-trailing-whitespace-only-applies.html

In their case it even means that when you are at the end of a line, press space or tab followed by any arrow key (or alike) the trailing whitespace remains in the file, despite the setting trim_trailing_whitespace = true.

By clarifying the expected behavior we can strive for more consistent between the various implementations. Right now on our website it says:

trim_trailing_whitespace: set to "true" to remove any whitespace characters preceding newline characters and "false" to ensure it doesn't.

I would suggest to add something like "in the file" after "whitespace characters".

[jednano]

This rule shall be implemented as a file-save operation. See https://github.com/editorconfig/editorconfig/wiki/Plugin-Guidelines#trim_trailing_whitespace

On file save, any/all trailing whitespace shall be removed. This means you could open up a tainted file, save it and all previously-existing trailing whitespace shall be removed, even though no file changes were made.

[ffes]

Is my suggestion to add "in the file" after "whitespace characters" a good one? If so, I will open a PR for that. Or do we need better wording?

[cxw42]

I have a metaquestion --- should questions like this one about the content of the specification be in this repo, or should they still be in editorconfig/editorconfig? My understanding has been that substantive questions went over in the editorconfig repo, but perhaps that has changed now that this repo is open.

[xuhdev]

@cxw42 I think this issue is properly raised here, because it is about changing the text to clarify some part of the specification, not about proposing changes to the substance of the specification.

[cxw42]

@xuhdev In view of #3 and your comment above, I suggest the Board consider disabling issues here, or changing the way editorconfig/editorconfig is used. #3 appears substantive to me, and I can't fault the poster for opening a specification issue in a repo called "specification" ;) . Another option would be to add an issue template here pointing people to the other repo, but the experience of Stack Overflow suggests that may not be 100% effective.

[xuhdev]

@cxw42 see editorconfig/editorconfig#398