Wire: Normalize line endings on text editor loading

[AbigailBuccaneer]

As per a straw poll in #1240, the text editor should should save files with consistent \n line endings. This would be easiest if we normalized any line endings (\r|\n|\r\n) when loading files.

[CaptainPRICE]

Normalizing like that without consent from end user will break multi-line strings!
But is anybody listening to me.. no :(

[AbigailBuccaneer]

You haven't actually mentioned anything to do with multi-line strings in #1240, and it's been over a month.

[Nebual]

How does it break multiline strings? They'll still have "a newline", it just won't be the same control characters (assuming anyone is actually editing e2's in literally Windows Notepad or whatever archaic Mac OS 9 editor)

[CaptainPRICE]

You haven't actually mentioned anything to do with multi-line strings

Oh I didn't? I thought I already said it. So, that's why I come up with idea of mixed and dominant EOL, so it does not force/normalize line endings, instead it persists them (for mixed), or detects the most dominant and then uses that sequence for EOL (for dominant)..
But, since that is too "complicated" and all want it simplistic, I left it for you guys, since the lazy/easy way (featureless) won the poll.

How does it break multiline strings?

It does screw things up, I have experienced some unexpected bugs when I worked on interpreter due to Wire Text Editor always using \n line endings, hence how I come up with suggestion...

[Divran]

How does it break multiline strings?

It does screw things up, I have experienced some unexpected bugs when I worked on interpreter due to Wire Text Editor always using \n line endings, hence how I come up with suggestion...

You still haven't said how it breaks it. In what way is it broken?

EDIT: I just tested this by removing all \r when opening AND saving the file. Now, only \n remains.

like this:

function EDITOR:SetText(text)
    text = string_gsub(text,"\r","")
    [...]

( inserted here https://github.com/wiremod/wire/blob/master/lua/wire/client/text_editor/texteditor.lua#L328 )

Then, I tried creating a text document using windows explorer in my data folder called "notepad.txt". I then opened the file using notepad. Not notepad++, not sublime, not E2 editor. Just regular old notepad. Then I wrote this in it

local S = "hello
world
multi
line
string
test"

print(S)

Then, I opened this file ingame in the E2 editor. Everything looked fine. I spawned it on the ground. Still fine. Printed in chat, still fine.

I then saved the E2 with the E2 editor. Still no issues. Then I opened the file again using notepad. Now, as expected, it looks like this:

local S = "helloworldmultilinestringtest"print(S)

but that's just because notepad is a shit editor and it can't handle these line breaks. So still, no issues here. The file still works fine in atom editor, sublime, or any other editor.

[AbigailBuccaneer]

Unless anybody can come up with a test case that would be broken by normalizing line endings, I think we should go ahead with this. I've yet to see any evidence to back up @CaptainPRICE's claims.

[CaptainPRICE]

I've yet to see any evidence

You still need the evidence? Again? k.
Here you see the multi-line string (with mixed line endings):

Now open the file in Wire Text Editor, right click eol.txt tab, and then click Save As, name it whatever you want (in my case, I named it eol-e2). Now, here is what Wire Text Editor have done to multi-line string, see:

Wire Text Editor completely screws multi-line strings, but since nobody cares, whatever... (I am fine because as I have already said..)
@AbigailBuccaneer Anyway, it still it is an issue, can you tell me why have you reopened the issue yourself and closed mine which have provided much more details?! This is just ridiculous.

eol.txt
eol-e2.txt

[Divran]

That's the whole point every one of us is trying to make, @CaptainPRICE . The whole point of doing this is to remove the useless "CR" (\r) characters, and only leave the "LF" (\n) characters. What you have given right there is the exact same thing I already demonstrated in my post above yours, and it doesn't cause any issues whatsoever.

We aren't listening to you because you STILL haven't given any evidence to how this would break anything.
You are only repeating over and over that it will break, but not HOW it will break, or WHY.

[Nebual]

Well, Price's example demonstrates how the new behaviour would alter an intentionally malformed "multiline" E2 - though really the only "valid" use case for such a string would be for storing binary data (ie. compressed data, ie. jpg/png/zip). As lua strings already don't support nulls (probably amongst other control characters), they're already not binary safe strings.

This change will mean \r's cannot be used in string constants - they'll need to be escaped (or chr() 'd), but anyone storing binary data in an E2 string constant (without base64ing it or similar) deserves to have their code broken lol.