bug-gnu-emacs
[Top][All Lists]
Advanced

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

Attachment: bug24315.patch
Description: Text Data


reply via email to

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