trim_trailing_whitespace togehter with insert_final_newline does not work

[BaumiCoder]

If trim_trailing_whitespace and insert_final_newline are true and end_of_line is not set,
the trailing white spaces are removed, but no final newline is added.

This Pull Request currently only contains a failing tests to show this issues, which I reported in ec4j/editorconfig-maven-plugin#139.

[ppalaga]

@BaumiCoder thanks for the test, now I see what you expect. The question is how should editorconfig-linters know which eol should it use if end_of_line is not set?

[BaumiCoder]

You are right, there is no default of end_of_line in the EditorConfig specification, but normally an application uses the operating system default if not configured otherwise. I also adjusted the test to show, that System.lineSeparator() is also expected to be used in the input and output in this situation.

(A common scenario, where you not use EditorConfig to handle the EOL characters, is to handle them with git. Every developer has the files with the native EOL character on their machine and the central repository has LF.)

[ppalaga]

I have filed a clarification issue editorconfig/editorconfig#570 so that we keep the behavior consistent over various agents interpreting .editorconfigfiles.

[ppalaga]

@BaumiCoder I wonder why you do not set end_of_line to avoid the current issue?

[BaumiCoder]

Currently, I have no active Java project, but in general using end_of_line inside a git repository is not a good way in my opinion.

The reason is that git handles EOL already. The remote repository contains all files with LF and locally this is changed to platform specific EOL. To make sure nobody uses another git setting for this when working with your repository, you can add * text=auto to your .gitattributes file.

If you want to use end_of_line from EditorConfig, you also have to adjust the git setting. Because if EditorConfig enforces e.g., lf, but git converts the EOL on Windows PCs to CRLF, you get mixed line ending. Therefore, not using the native EOL is more complicated to configure. Furthermore, some simple tools (e.g., search tools like grep) have no EditorConfig support and maybe get confused if the EOLs are not the platform specific ones.

[ppalaga]

Thanks for explaining @BaumiCoder.

Although I prefer the inverse approach to force git to use the backend EOLs locally, like

*        text eol=lf
*.cmd    text eol=crlf

I am still open to find a way to support your use case.

Here is my proposal:

• If insert_final_newline = true but end_of_line is not set for a file, then the default behavior is to throw an exception advising the user to either set end_of_line in .editorconfig or configure the default on editorconfig-linters/editorconfig-maven-plugin level.
• We add some sort of a mechanism to configure editorconfig-linters/editorconfig-maven-plugin what they should do in case insert_final_newline = true but end_of_line is not set. The options may include fail, warn, ignore, use_lf, use_crlf, use_platform_default. Setting use_platform_default would be your case.

WDYT?

[BaumiCoder]

I think a headless EditorConfig tool should behave the same as if I save the file in an editor with EditorConfig support. I tested with the editors VSCodium, IntelliJ, VIM and Kate on Linux. All of them using the platform default EOL. The CLI tool editorconfig-checker also reports a Final newline expected inside my example file. Therefore, I think that use_platform_default is the default for many other editors and tools. Why should the maven plugin behave differently?

However, I understand your use case, where you always want to specify your EOL with EditorConfig. Maybe this should be handled with a separate linting rule. This could check if every file has an end_of_line set, which (a) has insert_final_newline = true or (b) has anything set with EditorConfig. I am not sure if (a) or (b) is the more suitable condition for this linting rule. As this should be an opt-in linting rule (i.e., it is off by default) the users may should be able to config if (a) or (b) is the desired behavior in their projects. (Or even option (c): Check if EditorConfig is correct for the .gitattributes file of the repository)