IDE (IntelliJ IDEA) support for Raw String Literals

[Anna Kozlova]

Yep, intention - is a possible compilation fix. Pasting is processed
differently and required surrounding backticks are added.
Thanks,
Anna

On Fri, Apr 20, 2018 at 8:18 PM, Kevin Bourrillion <kevinb at google.com>
wrote:

> Just to be clear: I assume the intention you're both referring to is
> really nothing different from the usual "you have a compilation error and I
> think I know how you want to resolve it" situation. Correct?
>
> It is sensible to wonder if something should happen upon typing an
> interior backtick to prevent that error from ever happening, but I believe
> it will be rare that you are typing that backtick because you actually
> meant a literal backtick, so that's what makes it not worth doing.
>
> On the other hand, when I *paste* into the interior of a RSL, I can see
> some benefit to automatically plumping up the delimiters in response.
> Presumably what I am pasting is literal text that is all meant for the
> interior of this literal.
>
>
>
> On Fri, Apr 20, 2018 at 10:23 AM, Anna Kozlova <anna.kozlova at jetbrains.com
> > wrote:
>
>> at the end of the string (`abc<caret>`), the additional tick would move
>> the
>> caret outside (`abc`<caret>), like it works now for normal strings. If you
>> want additional quotes around RSL, there would be a separate surround with
>> action or dedicated intention.  My question was indeed about second case
>> only, thanks for mention this explicitly.
>>
>> On Fri, Apr 20, 2018 at 6:56 PM, Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>> > I think there are two cases:
>> >  - when you're at the _end_ of the string and the next character is the
>> > auto-inserted close quote;
>> >  - when you're in the _middle_ of the string.
>> >
>> > For the first case, I think treating it as you do with double-quote in
>> > regular strings is right; most of the time, when I type
>> tick-stuff-tick, I
>> > am ending my raw string literal, so ticks at the end of the string
>> should
>> > be considered to be the closing delimiter(s).
>> >
>> > For the second case, you've already got a well-formed RSL, and you're
>> > adding stuff in the middle.  I would bias towards (1), with the option
>> of
>> > an intention to add (or subtract) more ticks to the delimiter.  (The
>> > intention should skip over tick counts where the body would collide with
>> > the delimiter, and I'd think this should always be available on RSLs,
>> > regardless of whether I'm typing more ticks in the middle or not?)
>> >
>> > If what I want to do is break the thing up, I'll probably just type
>> > tick-plus-stuff-plus-tick, and if I ignore the offered intention, I'll
>> get
>> > what I want.
>> >
>> >
>> > On 4/20/2018 12:36 PM, Anna Kozlova wrote:
>> >
>> >> Hi guys,
>> >>
>> >> we started developing the support for raw literals and would like to
>> ask
>> >> what do you think.
>> >>
>> >> Given a string `a<caret>b` and press ` at <caret>, what is the expected
>> >> behavior?
>> >>
>> >> 1. Just insert tick: result is `a`b` where it would be parsed as raw
>> >> literal (`a`), unknown identifier (b) and new raw literal till the end
>> of
>> >> file. Second ` at the same position will fix parsing. If one tick was
>> >> intended, one would need to call an intention to fix the number of
>> quotes
>> >> around initial raw literal.
>> >>
>> >> 2. Add additional quotes around initial raw literal: result is ``a`b``.
>> >> Literal is valid but to get `a` + `b` expression, one need to go to the
>> >> string start/end and change the number of ticks or call an intention.
>> >>
>> >> It looks like to me that (1) would be needed more often, like each time
>> >> when one needs to dynamically compose a string. (2) is more about
>> injected
>> >> code in the raw strings which IDE could treat differently anyway. (It's
>> >> possible to create an IDE switcher between these strategies but still
>> the
>> >> default value would be needed.) I would love to see other use cases as
>> >> well.
>> >>
>> >> Thank you,
>> >> Anna
>> >>
>> >
>> >
>>
>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>