Trim trailing whitespace and ensure text files are POSIX compliant

[aaronfranke]

This PR updates the PHP scripts to output POSIX-compliant text files, which means text files that end in one \n character. This PR also runs the scripts and manually goes over files the script did not touch (like source .gltf files). I also added an .editorconfig file to give a hint to IDEs that they should automatically fix this problem if encountered. This PR also trims trailing whitespace.

[javagl]

With 659 modified files (including SVG and glTF), there's hardly a way to sensibly review this. I think that differentiating between the commit that changes the script, and one or multiple commits for the modified files, it could be clearer (so what exactly was the change to the PHP file that causes all these changes?)

But to start with a question waaaay higher: Where and how is this relevant?

[aaronfranke]

@javagl There are many utilities that expect text files to be POSIX-compliant text files, especially on Mac/Linux systems. For example, cat will behave incorrectly in those cases, with the next terminal prompt appearing on the same line as the file's "final line" (in quotes because, by POSIX standard, a line of a text file ends in \n, therefore any bytes following the final \n are extraneous characters not on any line of the text file per the standard). For example, GitHub itself will display warnings when text files do not end in a \n character. For example, C/C++ compilers will complain about this: older compilers had it as an error, newer ones have it as a warning, but still if you compile with warnings treated as errors then it won't compile. This repo isn't C/C++ code, but still, many users including myself have their IDEs configured to automatically fix this problem on save. So, to the point, having POSIX-compliant text files in every repo makes it easier to work with, for me and anyone else who has their IDE configured like me. Otherwise I either need to reconfigure my IDE temporarily, or manually discard changes in Git. Aside from that, I would argue having files consistent is beneficial for its own sake, and consistent with a standard is even better. Formatting is too important to ignore, but not important enough to spend time on, so it's good to have easy-to-follow rules.

As for reviewing, click the "Hide whitespace" check box in the "Files Changed" tab to make reviewing easier:

[aaronfranke]

There are 3 total lines of the PHP script changed to specifically add the \n, here is one case.

[aaronfranke]

I forgot I included these, I put these changes in here because otherwise the license in .reuse/dep5 gets generated as License: CC-BY-4.0 AND LicenseRef-LegalMark-Khronos AND with a trailing space and a trailing AND. But that should probably get another PR to fix this first. EDIT: So let's merge #248 first.

[javagl]

I'm aware of the constant background noise of \n vs \r\n , and there's even that Git autocrlf thingy that tries to avoid the confusion of choosing between two things by offering three options 🤪 . But I wasn't aware that there's an actual "issue" with the current state of this repo.

As a baseline, I'm skeptical for a change like this. So there was something in the .gltf files that was changed here. Imagine someone notices "Oh, model X should be green instead of red", and fixes that, and writes out a new version of that model, as a .gltf, with whatever tool that user is using. This .gltf file will then have again the "issue" that is fixed here.

The main point is that changing 659 files warrants some scrutiny. This is not C++ code, and when it's only about some IDE inserting an extra line, then this sounds like a configuration issue of the IDE, and not something that warrants such a wide-ranging change.

("Removing trailing whitespaces in .md" or so could be OK, but there are dedicated linters for that, and it would not affect the .gltf files...)

[emackey]

Removing trailing whitespaces in .md

Actually, a pair of trailing spaces in Markdown is often intentional. It was the original official Markdown way of adding a line break, before <br/> was allowed in Markdown. We used to use these, for example in the CC0 messages in the old glTF-Sample-Models repo (now archived).

https://www.markdownguide.org/basic-syntax/#line-break-best-practices

I've added some end-of-file fixes in #254. Perhaps this PR can be closed?

[aaronfranke]

For Markdown line breaks, I just opened PR #265, which should be merged ahead of this PR.