Fwd: Raw String Literals indentation management

[Kevinjeet Gill]

> In prior discussions, we included String::stripMarkers(String leftMarker,
String rightMarker) as a means to manage indentation.
> There was a general feeling, at the time, that String::indent() (then
String::stripIndent()) would dominate use and String::stripMarkers less so.
> We propose that we drop String::stripMarkers and provide a more
customizable indentation management using String::lines(LinesOptions...
options)and String::transform(Function<String, String> f).

I hope we don't see stripMargin() go. I think it succinctly solves the main
pain point
of Raw String Literals. I'm sure it's been considered but just to add my 2
cents, take
the following examples:

    String f = `
                | The content of
                | the string
                `.stripMargin("| ");
   String pyFragment = `
                | def somePythonFunction(self, a, b):
                |     if (a == None):
                |         a = {}
                |     else:
               `.stripMargin("| ");
   String pyFragment = `
def somePythonFunction(self, a, b):
    if (a == None):
        a = {}
     else:`.trim();

The annoying part of Raw String Literals is that some of the white space is
an artifact
of where the string literal occurs in the code (i.e. inside the class or a
function or deeper)
and some of the white space is meant to be included in the String.
Incidental whitespace and
significant whitespace. Without a VISUAL INDICATOR like a margin you either
have to ignore the
surrounding code formatting and align to column 0 to remove the incidental
whitespace like in python
(which is barbaric) or have counted the whitespace and hardcoded in an
indent(-4). The latter
introduces ambiguity and guesswork.
  "One tab equals one space 1 right?"
     "Does Intellij turn turn 4 spaces into tabs? 8? does vim?"
 "Ugh, is auto-indent going to mess up all of my Strings Literals?"
        "Is moving this String Literal into the inner class going to be
tedious?"
Not having some standard way to visually mark a margin just means it's
going to show up in
Guava 35 and Apache-commons4 but incompatibly.