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 <amae...@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.las...@oracle.com
> <mailto:james.las...@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>
>
>
