Okay, for this message I abandon rectangles and adopt Version 2 of the 
algorithm, as described by Brian (see below): a trailing blank line before the 
final delimiter is included in computing the leading whitespace prefix.

Now I return to an idea we’ve seen before:

> From: Tagir Valeev <amae...@gmail.com>
> Date: January 27, 2018 at 3:23:31 AM EST
> 
>    String html = `<html>
>      |  <head>
>      |    <title>Message</title>
>      |  </head>
>      |  <body>`.trimMargin();


Here Tagir used pipe characters to indicate the intended left-hand margin of 
the embedded material, and a trimMargin() method to remove them (and preceding 
whitespace on the line).

So: what if we allow use of that format, but instead of pipes, use double 
quotes?

String s = “””
           “    I am 
           “        a block of text
           “””;

This gives a sort of “partial rectangle” that looks nice, is semi-easy to edit, 
and works okay with proportional fonts (you may not get good alignment with the 
leading delimiter, but you can always get perfect alignment with the trailing 
delimiter).  However, functionally it really buys you nothing over what the 
indentation of the trailing delimiter tells you.  So you can use it or not.

Where this option shines is when you really don’t want that trailing newline, 
but do want specific indentation and don’t want to use a method call .indent(4):

String s = “””
           “    I am 
           “        a block of text“””;

So for this design I would suggest adding a rule that until you hit that 
trailing delimiter, either every line DOES have a leading “, or every line does 
NOT have a leading “ (error if the two styles are mixed).

If you want to use the style without leading “ but some line of content begins 
with “, then you have to escape it:

String s = “””
               \"I am 
                    a block of text"
           “””;

If you really don’t like using an escape (for one thing, it makes the relative 
indentation of content lines less clear), then use the other style:

String s = “””
           "    "I am 
           "         a block of text"
           “””;

You have choices.  I’m not entirely sure I like such a design, but I’m putting 
it out there for contemplation.


> On Apr 17, 2019, at 2:40 PM, Brian Goetz <brian.go...@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.go...@oracle.com 
>> <mailto:brian.go...@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.
> 

Reply via email to