Remove blanks at line endings

[stweil]

Signed-off-by: Stefan Weil sw@weilnetz.de

[codecov]

Codecov Report

Merging #140 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #140   +/-   ##
=======================================
  Coverage   37.77%   37.77%           
=======================================
  Files           9        9           
  Lines         998      998           
  Branches      212      212           
=======================================
  Hits          377      377           
  Misses        555      555           
  Partials       66       66           

Impacted Files	Coverage Δ
ocrd_tesserocr/binarize.py	22.95% <ø> (ø)
ocrd_tesserocr/crop.py	13.51% <ø> (ø)
ocrd_tesserocr/deskew.py	17.34% <ø> (ø)
ocrd_tesserocr/segment_line.py	63.63% <ø> (ø)
ocrd_tesserocr/segment_region.py	53.64% <ø> (ø)
ocrd_tesserocr/segment_table.py	0.00% <ø> (ø)
ocrd_tesserocr/segment_word.py	76.66% <ø> (ø)
ocrd_tesserocr/recognize.py	47.75% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a370312...96227d7. Read the comment docs.

[kba]

Trailing newlines are a bit annoying for me too but not so much that I want to mess with the git blame output (yes, there is -w but still).

[stweil]

We cannot avoid handling this problem: good editors remove such blanks automatically, so any time I edit one of those files, I am confronted with the problem, and so I am when I run git diff which shows the blanks considered wrong in red. That's why I prefer to clean the code in one step (and maybe add a git rule which prevents future blanks at line endings).

[bertsky]

Almost all of these are empty lines. This topic has come up over and over again, and I still haven't heard a good counter-argument:

Blank lines inside comments used to be recommended including proper whitespace indentation in PEP8. But that changed at some point. But even today, this convention is necessary if you want to copy code verbatim into the interpreter, and the compiler still accepts both forms. Pylint can be told not to mock the old convention when configured no-space-check=empty-line (as is the case here).

(The old convention also makes paragraph text processing/folding easier, e.g. in Emacs.)

[stweil]

I still think it would be good to follow the convention and avoid blanks at line endings, but close this issue to reduce the list of open pull requests.

[bertsky]

I still think it would be good to follow the convention and avoid blanks at line endings, but close this issue to reduce the list of open pull requests.

Yes, in the meantime I have seen these arguments, i.e. pylint does not support no-space-check=empty-line anymore anyway. So I agree now we should at least phase out the old convention. (I'll try to adapt my editor accordingly.)