RFR: Multi-line String Literal (Preview) JEP [EG Draft]

[Guy Steele]

One possibility is language enforcement: at the part of the processing of a multiline string where whitespace is stripped off to the left of the rectangle, it could be an error if that leading whitespace is not “spelled the same” on all lines from which it is being stripped.  I lean toward recommending this.

> On May 9, 2019, at 12:40 PM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> The proposed solution does not solve the mixed leading white space problem. As long as the white space is consistent across lines with the tabs, it works fine.
> 
> Otherwise, the developer has two solutions;
> 
> 1) Uuse your editor to detab or detab + entab. Either makes the white space consistent.
> 
> 2) Write a custom String::transform method that does the trimMargins thing.
> 
> String string = """
>     |> line 1
>     |> line 2
>     """.transform(s -> s.replaceAll("\\w*\\|> ", ""));
> The lone line discussion could fall out an automatic trimMargins solution, but it gets messy.
> -- Jim
> 
> 
> 
> 
> 
>> On May 9, 2019, at 12:59 PM, Tagir Valeev <amaembo at gmail.com <mailto:amaembo at gmail.com>> wrote:
>> 
>> Hello! 
>> 
>> Great draft, thank you. I'm especially happy that the expert group came to the conclusion that automatic builtin processing of the indentation is important. I proposed to do this in January, 2018 [1]. While the solution proposed in JEP draft is not as radical as proposed by me, I still like it better than the previous RSL proposal.
>> 
>> One thing which seems missing is dealing with tabs. What if user file is invented with tabs? Should they be also processed? More specifically, what is a "white space" in strip indent algorithm description? Only \u0020 symbol or \u0020 & \u0009? Or anything for which Character.isWhiteSpace() returns true? Also if tabs are included do single tab costs the same as single space? You may imagine that somebody pastes part of multiline string from StackOverflow where tabs were used for indent and see some unexpected results (e.g. indent changes for the untouched lines while visually in the editor pasted lines look having the same indent as surrounding ones). I admit that defining what is "expected result" is hard, especially taking into account that most editors provide a setting for the tab size and different users may have different tab size. Nevertheless I feel that tab handling should be explicitly spelled out (even if it's "tab is not considered as a white-space character").
>> 
>> With best regards,
>> Tagir Valeev.
>> 
>> [1] http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-January/000251.html <http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-January/000251.html>
>> чт, 9 мая 2019 г., 19:07 Jim Laskey <james.laskey at oracle.com <mailto:james.laskey at oracle.com>>:
>> At this point I think the only outstanding issue is long line continuation. While we can postpone continuation until a later release, I think we should at least lay out the details to see if we need to do anything now. I'll follow up with a (long line continuation) synopsis e-mail in a few.
>> 
>> Meanwhile, please review the JEP and comment back here.
>> 
>> Cheers,
>> 
>> -- Jim
>> 
>> 
>> html: http://cr.openjdk.java.net/~jlaskey/Strings/MLS/MultilineStrings.html <http://cr.openjdk.java.net/~jlaskey/Strings/MLS/MultilineStrings.html>
>> markdown: http://cr.openjdk.java.net/~jlaskey/Strings/MLS/MultilineStrings.md <http://cr.openjdk.java.net/~jlaskey/Strings/MLS/MultilineStrings.md>
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190509/f7add38c/attachment-0001.html>