IMHO, that is terminating each string on its own line.
I believe you are right about that. I don't see a problem with it whenever having a string on its own line doesn't affect the semantics, as is the case in an SQL statement (as you pointed out too.)
The IDE can be configured so that - upon pressing enter - it will insert
and place the caret.
That's not a very desirable solution. the IDE has to be configured to do it (that requires work) and adding those characters upon pressing <enter> isn't always desired. In addition to that, whether those characters are inserted automatically or not, they still clutter text. IOW, in the best case, the IDE can provide a limited amount of help (I'd say even calling it help is questionable) yet still be unable to really increase the legibility.
Usually its add or remove lines. Add/Remove is easy to do with quotes per line.
True but, it's even easier if quotes are not needed.
I do not dispute that it saves (up to?) 2 or 3 keypresses (per line). But are those worth the potential downsides? Other things that would have saved many more keystrokes have been rejected as syntactical sugar (and rightfully so).
My position on that feature is _not_ based on saving keystrokes (I'm not afraid of typing a lot), I support that feature because when used appropriately it results in greater readability and increase ease of maintenance. That's more than syntactic sugar.
Mind also: In the above, I merely reject the "sql" example, as an example for multiline strings. IHMO the sql example does not show any real meaningful savings.
The statement is much cleaner and easier to read. IMO, that's a meaningful improvement particularly considering that in a program that does a lot of database access, the improvement will take place in every SQL statement. As they say in the U.S Congress, a billion here, a billion there and pretty soon, you're talking about real money.
Luckily, the current string syntax discourage such abhorrent usage. Multiline strings will make this easier to write, and more likely to happen.
it will be a good day for programming when the most abhorrent thing seen in a program is the misuse of the multi-line string feature.
Why not have it in its own file, added as resource. Much more flexible.
Not really sure if that is more flexible. Another file to manage and, all the statements are in a "big bucket" instead of being defined where they are needed, i.e, no context locality.
You mean that the string like this:
'abcd ' + LineEnding + 'efgh' // has spaces in the first line
will not be possible to represent in new multiline form?
I believe that to be correct that such a line could not be represented using Akira's mult-line string feature. That said, that's an "educated guess" on my part. Akira could authoritatively answer your question.
As I said, I justify that claim with what I said in the other thread.
Please read again my post above, including the post I not only linked to, but quoted there.
I did and, as far as reading and understanding other people's code, the less cluttered the code is, the easier it is to read and understand.