When a string literal is too long to fit within the column limit, the
formatter breaks it into several lines. When breaking a string, the
formatter has always preferred to break it where there is already
whitespace in the string. That is, if the string can be made to fit
in the column limit by being broken at a whitespace character, then it
will not be broken at a location that does not have a whitespace
character. Take for example the string "some text". Even if the
column limit allows for 6 characters on the first line, it will get
broken into "some " and "text". This has always been the case.
However, the program did not consider escape sequences when looking
for whitespace in the string to break it at. Say the original string
has an escape sequence instead of a space like "some\ttext" or
"some\ntext". Before this patch, the program treated the \t or
\n as an ordinary character. It could break the string into
"some\nt" and "ext".
After this patch, the program will treat escape sequences for
whitespace characters as preferred locations to break the string at
just like ordinary unescaped whitespace characters. So the string
"some\ntext" will get broken into "some\n" and "text" when it is
too long to fit in one line, even if the column limit allows
"some\nt" to fit on the first line. And also \n is preferred over
other whitespace. That is, if a string that needs to be broken into
several lines has any newline \n escape sequence in it, and breaking
it at one of the newline escape sequences makes it fit in the column
limit, then it will get broken at one of the newlines.
This patch only affects strings that are too long. A string that
already fits in the column limit still will not get broken, even if it
has \n in it.
Can we add a unit test for escape sequences > \X which I assume this handles