Considering that the idea is to replace StrConst = 'Foo' + sLineBreak + 'Bar' making PLATFORM the default might indeed be the most sensible approach.
If that's what people really want, I'm not too picky either way.
Do I understand correctly that this then wouldn't be trimmed at all, because the first line doesn't have any spaces?
You do not I'm afraid. It is trimmed like you'd expect (so, in that case, completely trimmed such that there is no leading space left anywhere.)
I.E. it would look like this if displayed with WriteLn:
Upon encountering characters #32, #9, or #11, my code in the scanner checks two boolean values to determine whether or not to trim, which it toggles between true and false where appropriate: "first_multiline" (meaning we've just seen an opening backtick) and also "had_newline" (meaning we've just seen a newline character and are at the very beginning of the next line.)
The main block of code relevant to that is simply this:
#32,#9,#11 :
if (had_newline or first_multiline) and (current_settings.whitespacetrimcount > 0) then
begin
trimcount:=current_settings.whitespacetrimcount;
while (c in [#32,#9,#11]) and (trimcount > 0) do
begin
readchar;
dec(trimcount);
end;
had_newline:=false;
first_multiline:=false;
goto quote_label;
end;
"quote_label" there being exactly the top of the case statement containing that branch (which
must be re-entered after trimming in order to properly avoid EOF.)
I think I hit another bug. It doubles the line ending.
I get your expected results with an LF encoded file, but not with a CRLF one. Let me take a closer look at what's going on there. Thanks for really digging in to the testing!
Ok, I've identified the issue with your second bug-find here. The problem is the specific combination of "MultiLineStringLineEnding CRLF" with a source file that is itself already CRLF (or "MultiLineStringEnding PLATFORM" when "target_info.newline" is specifically #13#10, with a file that is already itself CRLF).
After reviewing it, I realized that my code does not currently quite properly account for a contiguous
sequence of #13 and #10, one after another, in those cases, and so both the #13
and #10 are replaced with a full #13#10.
("MultiLineStringLineEnding RAW" is
not affected by this regardless of the operating system or the nature of the file, however, because it does not ever intentionally write more than one character at a time.)
I'm fairly confident that I know what the best way to remedy this is, but I might not have a chance to do so until later today (am at work right now, haha.) As soon as I can though, I'll fix it, push the changes to github, and upload another new pair of patches.
Thanks again for really trying to find the edge cases! It's precisely the kind of thing I was hoping for when I asked for testers. Hopefully that's the last big-ish bug, but of course let me know if you find anything else.