Allow to escape newline with \ like in markdown #3228
Conversation
|
Don't think this PR should be merged because of #2389. I would give it an okay if this happens when |
|
It seems that #2389 will add two newlines while this will add only one. I don't see any conflict here. With |
|
Note: this PR doesn't allow to escape slash, so |
There's a conflict because single new lines should be ignored when |
| @@ -103,5 +103,5 @@ fn is_blank(s: &str) -> bool { | |||
| } | |||
|
|
|||
| fn merge_lines(lines: &[&str]) -> String { | |||
| lines.iter().map(|s| s.trim()).collect::<Vec<_>>().join(" ") | |||
| lines.iter().map(|s| s.trim().replace("\\n", "\n")).collect::<Vec<_>>().join(" ") | |||
There was a problem hiding this comment.
Note: this PR doesn't allow to escape slash, so \n will be rendered as {newline}
I'm always a bit cautious of doing our own escaping. We should be matching Rust's rules for escape sequences if we do this.
There was a problem hiding this comment.
Fixed in next commit: now \\\\ will be rendered as \\ and \\n will be rendered as \n.
Although, I still don't recommend to merge this PR
I60R
changed the title
| fn process_paragraph(lines: &[&str]) -> String { | ||
| lines | ||
| .iter() | ||
| .map(|ln| ln.trim()) |
There was a problem hiding this comment.
Maybe I'm misreading the commonmark spec but it doesn't sound like there can be spaces between \\ and \n which a trim would allow.
There was a problem hiding this comment.
Just checked the commonmark preview. one space after leaves a \\. More then one space after is treated as \\\n because of another hard break rule.
| } else { | ||
| None | ||
| } | ||
| }) | ||
| .collect() | ||
| } | ||
|
|
||
| fn process_paragraph(lines: &[&str]) -> String { |
There was a problem hiding this comment.
If we go this route, I'd like to see test cases for this to show we are matching expected commonmark behavior
| let mut chars = ln.chars(); | ||
| let mut ln = String::with_capacity(expected_len); | ||
| while let Some(c) = chars.next() { | ||
| if c == '\\' { |
There was a problem hiding this comment.
Without code fence support, we could accidentally create a hard break when we shouldn't and people can end up relying on that.
|
Closing out due to conflicts and lack of activity. |
Edit: the behavior was changed as I've described here — backslash escapes newline as described in CommonMark spec.
Syn transforms comments into raw string literals before parsing, so \n appears as \\n and propagates in
help=...argument. This PR fixes that.Related to #3198 and #1810.
Probably shouldn't be merged in its current form and it's not clear yet what side-effects it might cause...