emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] ox-icalendar: Unscheduled tasks & repeating tasks


From: Ihor Radchenko
Subject: Re: [RFC] ox-icalendar: Unscheduled tasks & repeating tasks
Date: Sat, 01 Apr 2023 08:30:26 +0000

Jack Kamm <jackkamm@gmail.com> writes:

> 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".

"\r*\n" looks safer.

> 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.

I see.
Looking at
https://icalendar.org/iCalendar-RFC-5545/3-1-4-character-set.html:

    There is not a property parameter to declare the charset used in a
    property value. The default charset for an iCalendar stream is UTF-8 as
    defined in [RFC3629].

So, we should probably override `org-export-coding-system', even when it
is set. iCalendar demands UTF8 anyway.

We likely want (according to 34.10.1 Basic Concepts of Coding Systems):

       The coding system ‘utf-8-emacs’ specifies that the data is
    represented in the internal Emacs encoding (*note Text
    Representations::).  This is like ‘raw-text’ in that no code conversion
    happens, but different in that the result is multibyte data.  The name
    ‘emacs-internal’ is an alias for ‘utf-8-emacs-unix’ (so it forces no
    conversion of end-of-line, unlike ‘utf-8-emacs’, which can decode all 3
    kinds of end-of-line conventions).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]