Looking at this I wonder if some {$MultiLineStringTrimLeft Auto} would be useful, so that it would simply automatically trim both statements to look the same...
A few people have indicated they'd like something like this. Would not be difficult to implement at all, as again the main logic for trimming is simply this, currently:
#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;
I'm unsure if there is precedent in the compiler for directives that take both numeric values
and "string" values, such as would be the case here, however.
I know how to implement it properly, so there's no concern there, but I'm just not sure if it would be considered more "idiomatic FPC compiler code" to have a separate {$MultiLineStringTrimLeftAuto} directive that just took ON or OFF as input.
In the case of having the separate directive, the above code would become something
roughly like this (untested for side effects!) block:
#32,#9,#11 :
if had_newline or first_multiline then
begin
if current_settings.whitespacetrimauto then
begin
while (c in [#32,#9,#11]) do
readchar;
had_newline:=false;
first_multiline:=false;
goto quote_label;
end
else if 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;
end;
In the case of "one directive that took either a number or AUTO", though, the code wouldn't change much at all as AUTO would likely just set current_settings.whitespacetrimcount to the maximum possible numeric value (currently 65535, as right now current_settings.whitespacetrimcount is a word field, chosen because all the four-byte max values seemed excessively huge to me while all the one-byte ones seemed a bit too small.)
This would work correctly and not slow anything down, because of course I wrote it so that the scanner always stops when there's no actual leading whitespace left anyways.
Option three would be "have the separate directive, but still just make it set the existing current_settings.whitespacetrimcount to the highest value possible."
All ways would work, and all are quite easy to pull off. I'd need to add a bit more logic to make it actually base itself on the source position of the first backtick, though. Which I think is possible, but perhaps
slightly more "involved" to implement.
Apart from that, do you have any particular thoughts on my implementation as it exists so far? E.G, is there anything that stands out to you as obviously "wrong" / e.t.c? Very interested in any input at all I can get on this to make sure it's as useful as possible in the long run.