The PyLint output is marking the erroneous location visually by using ^ in the next line. This indicator is always prefixed by multiple spaces and the line does not contain any further text. Now, it might happen that the indicator is between two source lines that use the same quote type. Since we detect quotes through our regex, this occurrence would qualify, effectively enquoting the linter indicator ^. As a consequence of our quote handling, we normally prevented quoted text from being split. However, in the described scenario, this is not desired, since we are not dealing with a regular quote (but an accidental mismatch).
Therefore, with this commit, we disable our quote handling for those multi-line quotes where one line fully represents a typical PyLint indicator line. This should restore the desired line-matching behavior.
Fixes CODEOCEAN-12N
Within a source code comment (beginning with # or \\), a user could write arbitrary text, including unmatched quotes " or '. This is not an error and should be supported. However, with the current implementation, we would also treat such a quote the same way as an original one. With this commit, we fix that erroneous behavior.
Fixes CODEOCEAN-XF
With the turtle graphics, some very long lines might be returned by Poseidon just after the CR (\r). In this case, our new normalization will fix the mistake, but the next message received (just a LF `\n`) will be forwarded to the clients unchanged. This is not desired, so that we filter this case separately.
After splitting the messages received into lines, we could still have a line break within quotes. Since we just want to modify terminating line breaks, we change the recognition accordingly.
In Python, a so-called doc string consists of a string encoded in three quote (starting and ending with """ or '''). These strings were not yet recognized correctly, so that line breaks there would cause further trouble with recognizing individual lines (which is important for the linter translation).
Previously, a message received with CRLF line endings was (incorrectly) converted to CRCRLF line endings (i.e., from \r\n to \r\r\n). Then, the splitting in individual lines could generate an "empty" line, just containing the newly-added CR line ending \r.
If a non-JSON message received contains quotes and is cut off weirdly, the following message might "quote" the line breaks. Then, we have an issue and cause \r\n\n for the further processing within the CodeOcean backend.
This change is required for Turtle output generated by the Python environment. Otherwise, drawing some images could add empty new lines (in the browser), since the original JSON message got split between the ending \r\n characters.
* This is based on Sentry issue CODEOCEAN-5W (linter translation failing due to \r in output)
* We cannot keep all "\r" messages but we must not forward the "\r" if it is a single message received after a valid JSON
