Hi,
I want to move Lix to LF line endings consistently across all operating systems.
Explanation: What are line endings (LF/CRLF)? (https://thetexttool.com/compare/crlf-vs-lf#what-are-they)
SituationDocumentation in
doc/ is CRLF. The levels in the
levels/ have a mish-mash between CRLF and LF endings. At least it's consistent within one file. Windows Lix generates levels/replays/options/... with CRLF endings. Lix on other OSes generates files with LF endings. Lix, in every version and on every OS, accepts and understands both CRLF and LF.
When I edit levels or receive levels, I run
dos2unix over everything before checking it into git, so that newer stuff is standardized to LF.
PlanConvert to LF all documentation, levels, ..., all text files in the repository. Ship only LF on all systems. This will be one big commit in the git repository that touches a lot of files at once:
507 files changed, 171,715 insertions(+), 171,715 deletions(-)Make Windows Lix generate levels/replays/options/... with LF, not CRLF.
ReasonsLF have been the default everywhere for over 20 years, except on Windows.
Notepad, Windows's default text editor, finally works with LF in Windows 10 and Windows 11. It shows each of LF and CRLF as a linebreak.
Before, in Windows 8 and earlier, Notepad linebroke only at CRLF. Such old Notepad would display a file with LF endings in a long single line. This is the reason why the Lix documentation in
doc/ has CRLF, and why I've kept CRLF in Lix's level/replay output. I like it if users can discover the formats and hack Lix at file level. But the Notepad problem doesn't exist anymore because Notepad has been fixed in Windows 10/11.
All Lix versions (forever) have understood both CRLF and LF. If newer Lix outputs LF on every system, it doesn't break backward compatibility.
I like LF more than CRLF.
Nobody should notice any new problem in the first place, unless he uses old Notepad or makes a
git diff of newer levels against the mish-mash level tree. (
git diff -w will ignore the line endings.) I have a soft spot for the Windows 7 users even though I've never used 7 myself. Those users should install a good text editor: Notepad++, Geany, ...
The UTF-8 Everywhere Manifesto (https://utf8everywhere.org/#faq.crlf) has a paragraph about line endings (https://utf8everywhere.org/#faq.crlf):
Quote from: https://utf8everywhere.org/#faq.crlfAlways use \n (0x0a) line endings, even on Windows. Files should be read and written in binary mode, which guarantees interoperability—a program will always give the same output on any system.
The UTF-8 Everywhere Manifesto is lovely in general. If you have some technical background, read it in full. :cute:
Advice from that explanation (https://thetexttool.com/compare/crlf-vs-lf) I linked at the start:
Quote from: https://thetexttool.com/compare/crlf-vs-lfStandardize on LF in your repository and data pipelines. Only convert to CRLF at the very end if a Windows tool requires it.
And there is no such requirement because Windows Lix has accepted LF forever.
-- Simon