To be clear: “closing delimiter influence” means that, before we strip off that
blank line, we look at how much whitespace it has, and we include that in our
calculation of “common leading whitespace prefix”. (This has been called a
“determining line” in prior discussions of alignment.).
The degree of control goes in one direction only; you can use this to
_decrease_ the amount of whitespace stripped by moving the closing delimiter to
the left.
I think we can assume that most of the time, users would prefer that the
opening delimiter line up with the closing one, especially if we are
essentially forcing them to put them on their own lines. Saying
String s = “””
stuff
“””;
feels more natural than
String s = “””
stuff
“””;
or
String s = “””
stuff
“””;
If we assume this to be the user’s default inclination, then “closing delimiter
control” is, in this common case, also “opening delimiter control”; that the
indentation from the opening quote is significant.
That means that to get left-aligned strings under this approach, the user would
have to do this:
String s = “””
stuff
more stuff
“””;
or this
String s = “””
stuff
more stuff
“””;
or this:
String s = “””
stuff
more stuff“””; // no trailing NL
And to get indented strings, they would do:
String s = “””
stuff
more stuff
“””;
So the tradeoff here is, as Jim suggests:
- More control over indentation
- Less ability to lean on an existing convention
Note that we seem to be leaning already towards using the position of the
closing delimiter to determine whether there is a trailing NL or not. I think
going all the way with this is something users could get their heads around.
So it seems a reasonable option. What do we think?
> On Apr 17, 2019, at 9:13 AM, Jim Laskey <james.las...@oracle.com> wrote:
>
> Brian points out that we under highlighted "closing delimiter influence".
> Liam eludes to it in his discussion, but I'll break the discussion out here.
>
> In the following example I'll use "." to indicate whitespace;
>
> String s = """
> ...............line 1
> ...................line 2
> ...........""";
>
> The outcome without closing delimiter influence;
>
> line 1
> ....line 2
>
> represents the result of only including line 1 and line 2 in the
> determination of the amount of whitespace needs to be removed.
>
>
> The outcome with closing delimiter influence;
>
> ....line 1
> ........line 2
>
> represents the result including line 1, line 2 AND the line containing the
> closing delimiter.
>
> The negative aspect of the including the closing delimiter line is that the
> fat delimiter pattern would have to deviate from the brace pattern.
>
> Cheers,
>
> -- Jim
>
>
>> On Apr 17, 2019, at 9:55 AM, Jim Laskey <james.las...@oracle.com
>> <mailto:james.las...@oracle.com>> wrote:
>>
>> To paraphrase McLuhan, I think that we need to keep the focus on the rider
>> and not the horse they rode in on. This was the main reason I pushed for
>> backtick over triple double quote; making it about the content and not the
>> syntax around it.
>>
>> In the Raw String Literal round, I suggested that
>>
>> String query = ```````````````````````````````````````````````
>> SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
>> WHERE `CITY` = ‘INDIANAPOLIS'
>> ORDER BY `EMP_ID`, `LAST_NAME`;
>> ```````````````````````````````````````````````;
>>
>> might freak out some developers.
>>
>> If you break this example down, the multiple quotes are not really for the
>> language, but instead for the eye of the beholder. Alignment wise, all the
>> language cares about is the first character of each of the delimiters. The
>> last character can be derived from the longest line based on end of line.
>> So this reduces down to
>>
>> String query = ``
>> SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
>> WHERE `CITY` = ‘INDIANAPOLIS'
>> ORDER BY `EMP_ID`, `LAST_NAME`;
>> ``; // need `` because of the enclosed backticks
>>
>> or in the fat delimiter world
>>
>> String query = """
>> SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
>> WHERE `CITY` = ‘INDIANAPOLIS'
>> ORDER BY `EMP_ID`, `LAST_NAME`;
>> """;
>>
>> In the incidental whitespace discussion, this aligns with closing delimiter
>> influencing indentation. Brian and I have been of four minds on this, where
>> I tend to favour closing delimiter influence and Brian tends otherwise. My
>> strongest argument thus far has been, "Swift does it."
>>
>> As you point out, management of literal boxing is nightmarish and heavily
>> reliant on IDE support, and I feel strongly that is a problem. I'm in and
>> out of BBEdit , VSC, Atom, and Coda as much as I am in Intellij. The IDE
>> answer doesn't work for me, and may not for (many?) others. What I do see
>> is an IDE putting a light gray box or a different background colour to
>> highlight the "auto aligned" string content.
>>
>> Bottom line, closing delimiter influencing indentation provides the same
>> information as boxing with less hassle.
>>
>> Cheers,
>>
>> -- Jim
>>
>>
>>
>>> On Apr 16, 2019, at 5:14 PM, Guy Steele <guy.ste...@oracle.com
>>> <mailto:guy.ste...@oracle.com>> wrote:
>>>
>>>
>>>> On Apr 16, 2019, at 4:02 PM, Brian Goetz <brian.go...@oracle.com
>>>> <mailto:brian.go...@oracle.com>> wrote:
>>>>
>>>> Indeed, it does solve a number of "figure out what was the user thinking"
>>>> questions.
>>>>
>>>> You hit the nail on the head regarding IDE support. Our original thinking
>>>> was that it should be easy to cut and paste between a (say) JSON document
>>>> and a Java source program, without having to mangle it up in an annoying
>>>> and error-prone way.
>>>>
>>>> I think what you're saying is, in the age of IDEs, that this is not such a
>>>> problem, and we should focus on what yields the most _readable_ code, on
>>>> the theory that writing is the job of the IDE?
>>>
>>> Yes, exactly. Though, as I pointed out in my subsequent message, it’s easy
>>> to give the programmer a choice between a quick-and-easy way to
>>> cut-and-paste that is easy to write, and a more labor-intensive or
>>> IDE-intensive version that may be easier to read (at least in some
>>> situations).
>>>
>>> At least we should explore such options.
>>>
>>> —Guy
>>>
>>
>
