From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30675: Ask the user what to do when shr-make-table: Variable binding depth exceeds max-specpdl-size Date: Fri, 13 Apr 2018 15:43:14 +0300 Message-ID: <83muy75lb1.fsf@gnu.org> References: <877eqwbqvc.fsf@jidanni.org> <87po4n19q0.fsf_-_@jidanni.org> <87bmeoc7e4.fsf@mouse.gnus.org> <87k1tc3r82.fsf@jidanni.org> <87h8ogar2w.fsf@mouse.gnus.org> <83r2nj5uaa.fsf@gnu.org> <87fu3z9vjt.fsf@mouse.gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1523623337 24808 195.159.176.226 (13 Apr 2018 12:42:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Apr 2018 12:42:17 +0000 (UTC) Cc: 30675@debbugs.gnu.org, jidanni@jidanni.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 13 14:42:12 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f6y1s-0006KY-49 for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Apr 2018 14:42:12 +0200 Original-Received: from localhost ([::1]:50766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6y3y-0001fX-Sm for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Apr 2018 08:44:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6y3i-0001bX-Ua for bug-gnu-emacs@gnu.org; Fri, 13 Apr 2018 08:44:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f6y3e-0004Ot-13 for bug-gnu-emacs@gnu.org; Fri, 13 Apr 2018 08:44:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41342) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f6y3d-0004Oi-Sv for bug-gnu-emacs@gnu.org; Fri, 13 Apr 2018 08:44:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f6y3d-0005lC-Ir for bug-gnu-emacs@gnu.org; Fri, 13 Apr 2018 08:44:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Apr 2018 12:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30675 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30675-submit@debbugs.gnu.org id=B30675.152362341922105 (code B ref 30675); Fri, 13 Apr 2018 12:44:01 +0000 Original-Received: (at 30675) by debbugs.gnu.org; 13 Apr 2018 12:43:39 +0000 Original-Received: from localhost ([127.0.0.1]:49239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f6y3B-0005kN-9H for submit@debbugs.gnu.org; Fri, 13 Apr 2018 08:43:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f6y36-0005k8-Mh for 30675@debbugs.gnu.org; Fri, 13 Apr 2018 08:43:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f6y2w-00049G-LO for 30675@debbugs.gnu.org; Fri, 13 Apr 2018 08:43:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46088) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f6y2w-00049B-HX; Fri, 13 Apr 2018 08:43:18 -0400 Original-Received: from [176.228.60.248] (port=2684 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f6y2v-0006P4-6h; Fri, 13 Apr 2018 08:43:17 -0400 In-reply-to: <87fu3z9vjt.fsf@mouse.gnus.org> (message from Lars Ingebrigtsen on Fri, 13 Apr 2018 13:48:22 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:145259 Archived-At: > From: Lars Ingebrigtsen > Cc: jidanni@jidanni.org, 30675@debbugs.gnu.org > Date: Fri, 13 Apr 2018 13:48:22 +0200 > > Eli Zaretskii writes: > > > I'd feel much better with a lower factor, e.g. some value that is just > > enough to cover this case plus some slack. Bonus points for providing > > a defcustom with the factor, so that users could change that. > > The problem is that HTML may nest arbitrarily deep, so there isn't > really any way to cover this completely. But the larger the stack size > is, the lower the possibility for hitting the limit is. > > FWIW, I haven't hit the limit in about a year, so it's rare for people > to encounter HTML that's that deeply nested. Which probably means ten-fold increase is too much. Would increasing the limit twice fix this problem? If so, then let's do that in shr.el. > why consult the user at all? :-) Because there's a possibility of infinite recursion. So the question actually boils down to "how much do you trust the code which caused this?" And I'm guessing the answer will tend to be NO with each additional prompt from the same command.