PROPOSAL: Multiline strings (EOL handling)

[rssh at gradsoft.com.ua]

> Embedding regexps has two significant advantages:
> .......
>

 I think that unescaped strings are useful not only for reqular expressions.
Embedding of special syntax for regexprs -- may be this is another issue
(and I afraid much less trivial  then this)

>
> As far as the multi-line string proposal: It is very incomplete. I
> suggest resubmitting it with documentation on handling raw strings
> (let's leave regexp literals for another proposal; as has been said,
> even if the language has regexp literals, raw strings are still a
> useful constrict), and on handling white space. It should also cover
> handling of newlines (if the file contains \r\n because it was written
> on windows, should those be kept as is or should they be replaced with
> \n line-endings, which seems like the right answer to me).
>

 Sorry, but handling of newlines is described:
<quotation>
After parsing multiline string is concatenation of lines with
inseted value of system property 'line.separator' between thems.
</quotation>

 And 'line.separator' is '\n' on unix and '\r\n' on windows.

 but yes, replacing all end of lines to '\n' (string normalizing)  make
sence. (I will add issue)

Yet on question: it can be optional or by default.

I. e. variant OPTIONAL:
a)  we can add suffix "u" or "w" for unix-like or windows-like EOL
handling and leave one as in program text by default.

variant DEFAULT:
b)  always normalize multiline strings, by replacing '\r\n' to '\n'


> My personal favourite way to do whitespace:
>
> After the first newline, eliminate all leading whitespace. Then
 ....
(Ok, will add issue [next letter will be about this to spit different
issues to different threads])