fix parsing of newline in RAW-LINE #60
Conversation
Previously, carriage return characters were not allowed in RAW-LINE. Since NEWLINE tested for linefeed or carriage return plus linefeed, this resulted in carriage return characters without a following linefeed causing havoc. See the added test. 3b#60
|
PAX needed small updates to follow up on these changes, but the output is now identical. |
Previously, a single carriage return not followed by a newline (as would be the case on Windows) would sometimes make the variable's docstring be presented as a verbatim block. This fix also needs 3b/3bmd#60 from 3BMD.
... and don't escape > because it's never necessary. Needs 3b/3bmd#60 from 3BMD.
|
will try to get to this soon, when i have more time to think about it. Looks reasonable from a quick skim though, aside from I'd probably name the I think there may be a few more edge cases to deal with to support other blocks correctly, though I'll probably merge this first either way. In particular I wonder about horizontal rules ( (If you want to work on it further before i get to it, might rebase onto the |
|
Thanks. I'll rebase and see how it works.
… Message ID: ***@***.***>
|
Previously, carriage return characters were not allowed in RAW-LINE. Since NEWLINE tested for linefeed or carriage return plus linefeed, this resulted in carriage return characters without a following linefeed causing havoc. See the added test. 3b#60
Previously, a single carriage return not followed by a newline (as would be the case on Windows) would sometimes make the variable's docstring be presented as a verbatim block. This fix also needs 3b/3bmd#60 from 3BMD.
... and don't escape > because it's never necessary. Needs 3b/3bmd#60 from 3BMD.
|
Seems to work fine after the rebase. Also tested along with a host of unrelated changes (except for "follow up on changes on 3bmd's rc branch"), PAX's dref branch (https://github.com/melisgl/mgl-pax/tree/dref). I'm unlikely to emerge from my PAX todo list. So this may be as far as I'll go on the 3bmd side of things. |
Previously, a single carriage return not followed by a newline (as would be the case on Windows) would sometimes make the variable's docstring be presented as a verbatim block. This fix also needs 3b/3bmd#60 from 3BMD.
... and don't escape > because it's never necessary. Needs 3b/3bmd#60 from 3BMD.
|
Well, I had to come back to this to fix the escaping of < and &. It think commit fbd1075 makes escaping correct for all special chars. It tries to use escapes economically, but utterly fails to do that with < and &. I guess, correctness first? |
The escaping is now print/parse consistent but overly aggressive in that it escapes "<->" as "\\<->" and "&KEY " as "\\&KEY ", which is not necessary.
Previously, a single carriage return not followed by a newline (as would be the case on Windows) would sometimes make the variable's docstring be presented as a verbatim block. This fix also needs 3b/3bmd#60 from 3BMD.
... and don't escape > because it's never necessary. Needs 3b/3bmd#60 from 3BMD.
Previously, a single carriage return not followed by a newline (as would be the case on Windows) would sometimes make the variable's docstring be presented as a verbatim block. This fix also needs 3b/3bmd#60 from 3BMD.
... and don't escape > because it's never necessary. Needs 3b/3bmd#60 from 3BMD.
Previously, a single carriage return not followed by a newline (as would be the case on Windows) would sometimes make the variable's docstring be presented as a verbatim block. This fix also needs 3b/3bmd#60 from 3BMD.
... and don't escape > because it's never necessary. Needs 3b/3bmd#60 from 3BMD.
Previously, a single carriage return not followed by a newline (as would be the case on Windows) would sometimes make the variable's docstring be presented as a verbatim block. This fix also needs 3b/3bmd#60 from 3BMD.
... and don't escape > because it's never necessary. Needs 3b/3bmd#60 from 3BMD.
Previously, a single carriage return not followed by a newline (as would be the case on Windows) would sometimes make the variable's docstring be presented as a verbatim block. This fix also needs 3b/3bmd#60 from 3BMD.
... and don't escape > because it's never necessary. Needs 3b/3bmd#60 from 3BMD.
Previously, a single carriage return not followed by a newline (as would be the case on Windows) would sometimes make the variable's docstring be presented as a verbatim block. This fix also needs 3b/3bmd#60 from 3BMD.
... and don't escape > because it's never necessary. Needs 3b/3bmd#60 from 3BMD.
|
Doesn't look like I'll have any energy for poking at edge cases, and seems like current state of the PR is an improvement in general even if there are some remaining, so will merge it and think about it more if we run into any specific problems later. |
Previously, carriage return characters were not allowed in RAW-LINE. Since NEWLINE tested for linefeed or carriage return plus linefeed, this resulted in carriage return characters without a following linefeed causing havoc. See the added test. #60
Previously, carriage return characters were not allowed in RAW-LINE. Since NEWLINE tested for linefeed or carriage return plus linefeed, this resulted in carriage return characters without a following linefeed causing havoc. See the added test.