fix(jira2markdown): process windows line breaks as a Unix line breaks #28
Conversation
catcombo
force-pushed
the
feature/fix-list-line-endings
branch
from
7857a24 to
445b489
Compare
catcombo
changed the title
|
@catcombo: I'll test it against my production pipeline today or tomorrow. Can you sync this branch with the latest master so my tests are based on the latest commits. |
catcombo
force-pushed
the
feature/fix-list-line-endings
branch
from
445b489 to
50029e0
Compare
catcombo
force-pushed
the
feature/fix-list-line-endings
branch
from
50029e0 to
5ed8b03
Compare
|
@arctus-io Sure. Done. Branch is rebased on top of the latest master. |
jira2markdown/parser.py
Outdated
| inline_markup << elements.expr(inline_markup, markup, usernames, filter(lambda e: e.is_inline_element, elements)) | ||
| markup << elements.expr(inline_markup, markup, usernames, elements) | ||
|
|
||
| text = text.replace("\r\n", "\n") |
There was a problem hiding this comment.
@catcombo: This currently works for me in my production workflow, however I would consider accounting for individual Carriage Returns (CR) )\r). It is not an edge case that currently breaks something in my workflow but could for someone else since it was a valid new-line on legacy Mac's.
text = text.replace("\r\n", "\n").replace("\r", "\n")There was a problem hiding this comment.
This is what I afraid of. I so not sure about these replacements. Probably this week I'll have more time to investigate how to do it with pyparsing. Lets wait until the end of the week.
There was a problem hiding this comment.
I pushed another version with a custom token for line endings. It works but now output contains mixed line endings. This is because converter doesn't change all characters in the string, but only ones that match predefined elements. Probably, it's not very good idea, but at least it works on the tokens level, not on the entire string without taking into account the string markup. What do you think?
There was a problem hiding this comment.
Alright, I found how to keep existing line breaks and reuse them if possible. Now in most of the cases line breaks in the converted string will be consistent. @arctus-io can you test it on your side?
Fixes #25