String reboot - (1a) incidental whitespace

[Brian Goetz]

Interesting idea.  This pushes towards the “let the language do as much as it can”, so that such indexes are maximally useful.  But I wonder if this approach is doomed to run out of gas anyway?  Because, even if we do auto-alignment, so there is a single ML string literal, there is likely to be substitution of some kind:

    String s = “””
        SELECT * from %s where (condition)
    “””.formatted(tableName);

Now, suppose there is an error in the condition; the column number will still be wrong unless the table name happens to have two letters in it.  And the same is true if we did the substitution via linguistic interpolation rather than by a call to a method like formatted().  


Coming back to the main question — and one that we hope could be answered by data — is whether it is common that embedded snippets will want some actual leading common whitespace (indentation) rather than being pushed as far to the left as they can go.  I suspect so — which is an argument in favor of allowing this to be controlled linguistically (assuming we’re doing our alignment linguistically in the first place.). 

> On Apr 17, 2019, at 2:53 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto:kevinb at google.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190417/af11e195/attachment-0001.html>