what constitutes code under this conditions? You seem to need more than the plain text, you seem to need the file to be sure?
The 100 % exact answer depends on the language. E.g., for D, it's UTF-8 text with CRLF or LF endings (which both behave similar to a space I think). The text can be in a file, but need not be. Non-Unicode encodings aren't valid D. ASCII is a subset of UTF-8 and thus valid unicode.
If I open one of the Lix source files on github, mark the text and copy the content in a text file, then it doesn't seem to convey the file endings but only the plain text? (Notepad shows it then properly as opposed to copying it from the file itself.)
Interesting phenomenon. From
this gif, I assume that Windwos's copy buffer is encoding-agnostic. If you somehow get LF text inside the copy buffer, it will come out as LF text.
Now, according to
atom editor issue 8365's first post, most text editors convert LF to CRLF when you copy, such that only CRLF text makes it into the copy buffer.
I assume your webbrowser behaves the same: When it renders HTML or a text file for you, it silently converts the displayed text to CRLF once you highlight & copy.
_trapMouse = true; (l. 151)
The spaces make sense because so everything is neatly in line but if I do find and replace it seems to be seen as a different string of signs.
Excellent catch.
These spaces have no meaning, but make the editing harder, unnecessarily. They affect search & replace. When one of the neighboring lines change, the alignment becomes wrong anyway, and we would have to make larger changes than necessary (re-align all lines in the block), then the change will be harder to understand.
Especially older parts of the source still have these decorative spaces for alignment with neighboring lines. I try to not put them anymore into any code. I admit that the habit is hard to break.
Yeah, I assumed you had change this line as well. My bad for not finding this in your attached mouse.d. <_<;; I took a brief look at the file back then, you didn't change anything but such lines, but didn't check whether you found every single occurrence.
In Lix, I won't stop accepting/outputting CRLF on Windows. I've merely found the Zig rules an unexpected example of how far you can take stylistic rules. And I hope that the discussion was not considered trolling, even though in hindsight, it may easily look like it.
Whenever I create the Windows Lix download, I should probably convert all levels to CRLF.
For git, it's possible to configure per repository (I haven't done it so far) how levels should be checked out (e.g., have them as LF in the repo but CRLF in a Windows worktree). Sadly, the repo has half-LF, half-CRLF levels, even though I've paid attention for a while now to check in only LF levels.
-- Simon