<div dir="ltr">This has been discussed I think several times in the past, but I thought I'd bring it up once more as it has never made sense to me that FPC happily supports multi-line <b>comments</b> of any length, while having no such multi-line equivalent for string literals.<div><br></div><div>I was fiddling around with what the clearest, easiest-to-parse, and most similar-to-existing-syntaxes way of doing it would be, and came up with this:</div><div><br></div><div>const MultiLineString = (##<br>  'The<br>   line<br>   endings<br>   would<br>   be<br>   implicit<br>   here.<br>   This<br>   is<br>   significantly<br>   cleaner<br>   looking<br>   overall<br>   IMO!'<br>##);</div><div><br></div><div>The rationale being: round-bracket-plus-double-pound-sign is an uncommon enough combination of characters that it is highly unlikely to conflict with anything anyone currently has written inside of a string literal, and also relatively similar to the classic round-bracket-plus-apostrophe multi-line-Pascal-comment syntax.</div><div><br></div><div>(It could even be reduced to just one pound sign after the opening bracket and before the closing bracket if that was deemed "safe" to do, but I was just trying to play it safe here.)</div><div><br></div><div>So the grammar rules would be:</div><div><br></div><div>Any instance of (## <b>must</b> be immediately followed by a single apostrophe. After that, a string is parsed, line by line, until another single apostrophe is hit. That second apostrophe <b>must </b>be immediately followed by ##) and then finally a semicolon to "terminate" everything.</div><div><br></div><div>Note that in Lazarus, for example, everything from the opening (## to the closing ##) would be highlighted in blue just as multi-line comments and <b>unbroken </b>string literals currently are, making them stand out nice and clearly.</div><div><br></div><div>To compare that directly to the current way of doing multi-line strings:<br><br>const SingleLineString =<br>  'No' + sLineBreak +<br>  'implicit' + sLineBreak +<br>  'line' + sLineBreak +<br>  'endings' + sLineBreak +<br>  'are' + sLineBreak +<br>  'currently' + sLineBreak +<br>  'available.' + sLineBreak +<br>  'I' + sLineBreak +<br>  'fail' + sLineBreak +<br>  'to' + sLineBreak +<br>  'see' + sLineBreak +<br>  'how' + sLineBreak +<br>  'this' + sLineBreak +<br>  'syntax' + sLineBreak +<br>  'is' + sLineBreak +<br>  'preferable' + sLineBreak +<br>  'in' + sLineBreak +<br>  'any' + sLineBreak +<br>  'way.';<br></div><div><br></div><div>I simply don't, personally, see any argument in <b>favor</b> of the current way. (Much more "line noise" due to all the apostrophes, addition signs, and "sLineBreaks", and of course no consistent blue syntax highlighting in IDEs, as well as the fact that it's much more difficult to make use of already-formatted-like-you-want-it text that way, and so on.)</div><div><br></div><div>Thoughts?</div></div>