Skip to content

Conversation

@aaronfranke
Copy link
Contributor

@aaronfranke aaronfranke commented Nov 14, 2025

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
Copy link
Contributor

javagl commented Nov 14, 2025

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
Copy link
Contributor Author

@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:

Screenshot 2025-11-14 043345

@@ -504,10 +511,10 @@ public function writeReadme ($tagListings=null) {
$readme[] = $this->metadata['credit'][$ii];
}
//$readme[] = "#### Assembled by " . AppName . ' ' . AppVersion;
$readme[] = "#### Assembled by " . AppName;
$readme[] = "#### Assembled by " . AppName . "\n";
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

'link'=>'',
'text'=>'Cesium Trademark or Logo',
'spdx'=>'LicenseRef-LegalMark-Cesium',
),
'LicenseRef-LegalMark-DGG' => array (
Copy link
Contributor Author

@aaronfranke aaronfranke Nov 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

javagl commented Nov 14, 2025

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...)

@aaronfranke aaronfranke marked this pull request as draft November 14, 2025 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants