On Fri, Aug 26 2016 at 23:35, npostavs@users.sourceforge.net wrote:

> This looks like it would be an inefficient regexp, since it has nested
> stars.  I suspect searching for "^[ \t]" multiple times would be more
> efficient than trying to match multiple lines in a single regexp.

Tried that.  It sort of worked, in that it worked when I directly called
`icalendar--read-event' in a buffer containing the event as manually
extracted from the gnus message.

However, parsing the problematic message in gnus still failed.  It turns
out `gnus-icalendar-event-from-buffer' calls
`icalendar--get-unfolded-buffer' before `icalendar--read-event'.

`icalendar--get-unfolded-buffer' takes care of all those pesky line
continuations, and returns a buffer with each element occupying exactly
one line.  So essentially `icalendar--read-event' was using a regexp to
extract the rest of the line, and that failed with a line nearly 40k
characters long.

The only other in-tree caller of `icalendar--read-event' (excluding
itself) also calls `icalendar--get-unfolded-buffer' first, and indeed,
`icalendar-read-event' already relies on this to take care of line
continuations in element parameters (as opposed to values).

Attached is a patch that uses buffer-substring to accomplish the same
thing as the offending regexp, and documents the dependency on
`icalendar--get-unfolded-buffer'.  This fixes the problem for me.