stripIndent() behavior

[Kevin Bourrillion]

On Tue, Mar 13, 2018 at 6:47 AM, Jim Laskey <james.laskey at oracle.com> wrote:

C. Margin management. With introduction of multi-line Raw String Literals,
> developers will have to deal with the extraneous spacing introduced by
> indenting and formatting string bodies.
>
> Note that for all the methods in this group, if the first line is empty
> then it is removed and if the last is empty then it is removed. This
> removal provides a means for developers that use delimiters on separate
> lines to bracket string bodies.


+1 I think this is a good idea, which I didn't notice at first. For Google
Style, I can imagine ending up requiring newlines inside the delimiters, as
it makes the raw text embedded in your source code fit nicely into an
imaginary rectangle.



> public String trimIndent()
> This method determines a representative line in the string body that has a
> non-whitespace character closest to the left margin. Once that line has
> been determined, the number of leading whitespaces is tallied to produce a
> minimal indent amount. Consequently, the result of the method is a string
> with the minimal indent amount removed from each line. The first line is
> unaffected since it is preceded by the open delimiter. The type of
> whitespace used (spaces or tabs) does not affect the result as long as the
> developer is consistent with the whitespace used.
>

(now stripIndent)

I've accumulated a few questions/comments on this.

1. When choosing the amount to trim, it ought to ignore blank lines and
only-whitespace lines, right?

2. Is it really appropriate to automatically remove trailing whitespace? My
feeling is that if it creates some kind of problem at runtime, they can
just remove it from their source. Or call the method that's explicitly for
that. But in general... tws in, tws out...?  (Again though, lines that are
otherwise empty aside from tws need to not gum up the works (#1).)

3. If the input contains *any* tab characters at all (except any that are
part of the trailing whitespace), then this method cannot know that it
isn't jumbling the end result, and maybe it should just throw. Google Style
completely banishes tabs from source flies, but among the many projects
that don't there are going to be countless examples where tabs and spaces
are mixed in a haphazard fashion that the developer isn't even remotely
aware of. We should consider whether we're comfortable with surprising
realignment of their text, or would be better off throwing. The remedy for
the user in that case is either to nuke the tabs from this part of their
source, or call a method like `detab(int myTabStop)` first.

4. Honestly, my #1 complaint with this method is that it is so well-suited
to the needs of RSLs embedded in Java source that we are going to want to
call it every. single. time. As unpleasant as that sounds, at this point I
think all the alternatives might be considerably worse. So, this isn't
going to end up making the language feature itself feel very elegant. I
really wish we could come up with two syntactic options so that one could
be auto-unindenting, but I know how hard that would be.

5. If we do end up in a world where we have to call this for almost every
one of our tens of thousands of multi-line RSLs... is it strange that I
feel like I would prefer it was static? It seems like it would look a lot
more normal that way visually. Ugh...

foo(
    bar, `
        first line
        second line
        third line
    `.stripIndent(),
    baz);

vs.

foo(
    bar,

    stripIndent(`

        first line
        second line
        third line
    `),
    baz);



I don't feel great about this, but I just really don't feel happy about all
our RSLs looking like the top snippet.


public String trimMarkers(String leftMarker, String rightMarker)
>

At first, I was drawn to this method, because I liked how it clearly
"called out" the sections that were embedded RSLs and made them stand out
from the surrounding code. (When I imagine a long RSL that itself contains
Java code, and then I open my editor somewhere in the middle of that - wow,
how misleading!)

However, I quickly realized that the markers are terribly invasive, ruining
your ability to paste in, paste out, and rewrap paragraphs. And although I
could use this when I want conceptually to stripIndent but I need to
preserve a certain fixed amount of indentation on every line, I still think
I would rather use stripIndent and then just call a method to restore the
specific amount of indentation I want.

So in summary, currently I can't see why we would ever use this method. FYI.

On top of *that*, I have no idea what "right markers" are good for, nor
what customizing the marker choice is good for (other than creating more
needless variation between different pieces of code).


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com