Adds FileEmptyLastLineSniffer and FileEmptyLastLineFixer

[NickSdot]

Closes #49

The comment in the issue reminded me that this was still open. Though, not sure I understood what the comment was about but if I got it right then.editorconfig is the answer. Most repos already have it; for the five that do not have it I will open a PR.

[hakre]

The comment in the issue reminded me that this was still open. Though, not sure I understood what the comment was about but if I got it right then .editorconfig is the answer. Most repos already have it; for the five that do not have it I will open a PR.

Yes, also IMHO .editorconfig is able to carry the answer: It is "worktree aware", meaning: editor processes that have editorconfig plugged-in can handle newline configuration during file save operations:

# EditorConfig is awesome: https://editorconfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true

(Example: The first 10 lines of the Example file from https://editorconfig.org)

I personally think it is good to consider it here, the filename is well known and a common one in the folklore,
furthermore in scope of the issue/changeset I'd also recommend the unix-style configuration which I think you had in mind in the first place. If some Winows users are in the audience, they should be minded though as otherwise an authoring guide may fall short for the portability constraints that are at play.

I'd assume in good faith however, they have it configured in their content tracker for their system. This is in part because the content repositories themselves also have file attributes, e.g. text/binary encoding or the eol-marker.

Given any file contents for example, when the content is tracked with the git(1) utility, then in my understanding it is the parenting configuration as editorconfig is part of the tracked contents.

To mirror the editorconfig example above as gitattributes:

# Unix-style newlines with a newline ending every text, not binary, file
* text=auto
* text eol=lf

(commonly a windows user has either eol=crlf attributed here or is making use of the auto-crlf feature configuration.)

An Editorconfig file is in the tracked content (only if one was added obviously), and furthermore it allows to mark a root filepath so that editor processes that store files are able to translate the filepath information. Editorconfig needs no heuristic nor configuration for the file type (text or binary), as it is the author who decides which files to edit (commonly text files only).

For example, CS-Fixers in worktree mode, like all editors, are able to obtain the configuration for filepaths independent to any content tracking from the editor configuration alone - the configuration in the worktree suffices (a.k.a. in-tree editing, the authoring activity, the worktree thing).

Considering a worktree flag (as brought up in #49) could help to clarify what an editor-configuration potentially could mean for a fixer.

Hope this helps to grasp a bit this 'worktree' parameter on the somewhat abstract example with a suggested editor configuration.

And thank you for the initiative to share your code and thoughts here.