String reboot - (1a) incidental whitespace

[Kevin Bourrillion]

Really sorry for misreading that and seeing a "version 3" you weren't
talking about. In my defense Liam and I had recently been talking about
version 3 so I just accidentally mapped it on to this discussion. :-)
Thanks as ever for the patient explanation.

I may not have a *strong* position on this debate then.

But here's something to think about. A *lot* of our multiline use cases are
an embedded language like sql/xml/etc.; I think even a small *majority*.
These get parsed. Parsing sometimes throws an exception. Remedying such an
exception is of course a key developer workflow.

At some point soon I think we should propose a new interface to be
implemented by such exceptions, that defines the methods for getting either
line-and-column or character offset of the parse error (potentially a list
of such). When an IDE displays such an exception to a user, that user will
want to click on it and be taken to the correct position in their Java
source file that this location represents.

This is a bit of a disadvantage on anything that requires users to
postprocess their multiline strings e.g. with `.indent(4)`. It's not
impossible that an IDE might grok and compensate for that call, it just
starts to get a little weird.



On Wed, Apr 17, 2019 at 11:40 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Where this makes a difference is:
>
> String s = “””
>                I am
>                    a block of text
>            “””;
>
> Under Version 1, we would get:
>
> I am
>     a block of text
>
> Under version 2, we would get
>
>     I am
>         a block of text
>
> Under version 1, if we wanted the latter answer, we would have to do
> .indent(4) or something like that.
>
>
> On Apr 17, 2019, at 2:33 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>
> I'm sorry I'm not completely caught up on this discussion yet and may have
> missed something. But I'm confused what the alternative to using the
> closing delimiter position is. You certainly don't want to magically use
> the column position of the *opening* delimiter in this example!  That is
> *definitely* incidental, as it depends on what the `query` variable got
> renamed to later by some refactoring tool. Variable renames shouldn't
> change program behavior.
>
>
> Version 1 of the algorithm is:
>  - Strip leading and trailing blanks (perhaps limited to one each only)
>  - Compute the maximal common whitespace prefix of the remaining lines,
> and trim that off each line
>  - If a blank last line was trimmed, add back a newline
>
> Version 2 of the algorithm — the “significant closing delimiter” version —
> is:
>  - Strip leading and trailing blanks (perhaps limited to one each only)
>  - Compute the maximal common whitespace prefix of the remaining lines,
> _including the stripped trailing blank line from above, if any_, and trim
> that off
>  - If a blank last line was trimmed, add back a newline
>
> In other words, the difference is wether we strip off the trailing blank
> before or after we compute the leading whitespace prefix.  In neither case
> do we use scanner position.
>
>
>

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190417/654340a6/attachment.html>