The positive aspect; having control of indentation at the literal level.
> On Apr 17, 2019, at 10: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
>>>
>>
>
