[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24315: 25.1.50; re-search-forward errors with "Variable binding dept
From: |
Peder O. Klingenberg |
Subject: |
bug#24315: 25.1.50; re-search-forward errors with "Variable binding depth exceeds max-specpdl-size" |
Date: |
Tue, 30 Aug 2016 15:09:34 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
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.
bug24315.patch
Description: Text Data