[fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Pascal Riekenberg]

> "J. Gareth Moreton" <gareth at moreton-family.com> hat am 4. Juli 2019 um 07:45 geschrieben:
> 
> 
> 
> On 04/07/2019 06:31, Sven Barth via fpc-devel wrote:
> > Am 04.07.2019 um 01:57 schrieb J. Gareth Moreton:
> >>
> >> While I like the idea in principle, one thing that I'm a bit worried 
> >> about is how whitespace is handled, like what counts for a leading or 
> >> trailing space in the string when between lines, since Pascal parsers 
> >> (and those for many other languages) traditionally, I believe, 
> >> discard everything following the last non-whitespace character in a 
> >> line.  Also, with the backtick suggestion, what should one do if they 
> >> wish to include a control character (e.g. a linefeed) or the backtick 
> >> character itself?
> >>
> > Whitespace is indeed an important point. I myself pay quite some 
> > attention to nice identation and with multiline strings that will 
> > probably break:
> >
> > === code begin ===
> >
> > const SomeString = `Whatever
> >                                      bar
> >                                      blubb
> >                                      foobar`;
> >
> > === code end ===
> >
> > That's how I also inline my normal multiline strings that I separate 
> > with sLineBreak. However to get the same result with this proposed new 
> > feature I'd have to do this:
> >
> > === code begin ===
> >
> > const SomeString = `Whatever
> > bar
> > blubb
> > foobar`;
> >
> > === code end ===
> >
> > Which looks just ugly.
> 
> 
> I can definitely see that being a sticking point for such a feature with 
> no easy way to solve it, except to introduce a $INCLUDESTRINGFILE 
> compiler directive, since if the string is so long that it requires the 
> spanning of multiple lines and not using the existing means of extending 
> a Pascal string onto multiple lines, then it probably should be stored 
> in an external text file to be merged upon compilation.
> 
> It's a shame, because I like the feature in principle, but the 
> whitespace problem is a bit of a deal-breaker for me.  Also, things like 
> trailing spaces and the line terminators being either #10 or #10#13 may 
> cause a lot of problems if the string has to be known exactly (e.g. for 
> cryptographic hash generation).
> 
> Gareth aka. Kit
> 

What about a Lazarus-Addon / Codetools extention that generates an old style
multi-line string from a selection and the other way around to make old style
multi-line strings editable again, so you can keep indention and trailing and
leading whitespaces and special characters.

Pascal