Ihor Radchenko <yanta...@posteo.net> writes: > I now only have one minor concern about `org-icalendar-fold-string' when > the original buffer contains DOS line endings. May they mess things up > producing \r\r\n?
There are 2 issues here: what does `org-icalendar-fold-string' do when string already contains \r, and what does `org-export-to-file' do when `org-export-coding-system' or `buffer-file-coding-system' is dos-like. In both cases, the patch doesn't change the existing behavior -- which is to produce \r\r\n. For issue 1, what `org-icalendar-fold-string' does when string already contains \r\n, you can see that it produces \r\r\n as follows: emacs -Q -l ox-icalendar M-: (org-icalendar-fold-string (org-icalendar-fold-string "Line1\nLine2")) This is why the patch removes the calls to `org-icalendar-fold-string' in `org-icalendar--vevent' and `org-icalendar--vtodo' -- otherwise we would add \r multiple times to the same string. To change this behavior of `org-icalendar-fold-string', we could modify the patch to do: (defun org-icalendar-fold-string (s) "Fold string S according to RFC 5545." (replace-regexp-in-string - "\n" "\r\n" + "\r*\n" "\r\n" which would strip out any extra \r at end of line. Another alternative would be to use "\r?\n" instead of "\r*\n". For the second issue -- when `org-export-coding-system' is dos (or similar), the file created by `org-export-to-file' will contain \r\r\n. This was already the pre-existing behavior, but note the patch does cause a minor change here: before the patch just the main body will have \r\r\n, but after the patch, the preamble will also have it.
