Inconsistent newline encoding & decoding?

[d-e-s-o]

I am not sure if the following is expected behavior:

--- tests/reserialize.rs
+++ tests/reserialize.rs
@@ -1,5 +1,8 @@
 #![cfg(feature = "parser")]
-use icalendar::parser::unfold;
+
+use std::str::FromStr as _;
+
+use icalendar::{parser::unfold, Calendar, CalendarComponent, Component, Todo};
 use pretty_assertions::assert_eq;

 const SAMPLE: &str = "\
@@ -50,3 +53,21 @@ fn reserialization() {
     println!("{}", reserialized);
     assert_eq!(SAMPLE, reserialized);
 }
+
+#[test]
+fn reserialization_multi_line_description() {
+    let desc = "multi-\nline\ndescription";
+    let mut todo = Todo::new();
+    todo.summary("summary");
+    todo.description(desc);
+    let calendar = Calendar::from([todo]);
+
+    let serialized = calendar.to_string();
+    let deserialized = Calendar::from_str(&serialized).unwrap();
+    let deserialized_todo = match deserialized.components.as_slice() {
+      [CalendarComponent::Todo(todo)] => todo,
+      _ => unreachable!(),
+    };
+    let deserialized_desc = deserialized_todo.get_description().unwrap();
+    assert_eq!(deserialized_desc, desc);
+}

This test fails:

running 1 test
thread 'reserialization_multi_line_description' panicked at tests/reserialize.rs:72:5:
assertion failed: `(left == right)`

Diff < left / right > :
<multi-\nline\ndescription
>multi-
>line
>description


note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test reserialization_multi_line_description ... FAILED

It seems as if newlines are encoded to \\n (correct) but then never decoded back to \n in this scenario. I'd expect that at the level of a Todo object, I as the user shouldn't have to deal with such encoding matters -- it should all happen transparently. So I am wondering: Is this behavior intended?

[d-e-s-o]

The following patch seems to fix the test:

--- src/parser/utils.rs
+++ src/parser/utils.rs
@@ -81,6 +81,7 @@ pub fn line_separated<'a, O, E: ParseError<&'a str>, F: Parser<&'a str, O, E>>(
 /// ```
 pub fn unfold(input: &str) -> String {
     input
+        .replace("\\n", "\n")
         .split("\r\n ")
         .flat_map(|l| l.split("\n "))
         .flat_map(|l| l.split("\r\n "))

though I am not convinced that it is doing truly the correct thing at the right point in time (one indication being that it causes the folding_consistency test to fail).

[Neudrino]

I recently experienced issues with newlines in ICS files.

In short: Some downstream software might not have a fully RFC5545 compliant implementation and only allow \n as newline, but not \N.
So I would consider a conversion of \n to \N undesired and potentially harmful. In my experience, most software regards \n as default line end delimiter, such this should be the default for this library too (over \N).

For reference, this was first reported in qwandor/dancelist#511. That software does not do any icalendar stuff itself but relies on this library. The non-RFC5545-compliant were found further downstream.

I am aware that this might be slightly different than the topic originally reported, but maybe close enough, that it would fit here as well.
If you see it unfit to be paired in this thread, let me know, please. I can gladly open a new issue and am sorry if my adding here would cause any inconvenience.