GNU bug report logs - #30675
Ask the user what to do when shr-make-table: Variable binding depth exceeds max-specpdl-size

Previous Next

Package: emacs;

Reported by: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>

Date: Fri, 2 Mar 2018 02:41:01 UTC

Severity: wishlist

Tags: fixed

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #10 received at control <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 30675 <at> debbugs.gnu.org, Katsumi Yamaoka <yamaoka <at> jpl.org>
Subject: Re: bug#30675: Ask the user what to do when shr-make-table: Variable
 binding depth exceeds max-specpdl-size
Date: Thu, 01 Mar 2018 21:51:36 -0500
severity 30675 wishlist
quit

積丹尼 Dan Jacobson <jidanni <at> jidanni.org> writes:

> Instead of warning the user when this happens
>
> KY> (defun shr-descend (dom)
> KY>   ...
> KY>     (if (> shr-depth (/ max-specpdl-size 15))
> KY> 	(setq shr-warning "Too deeply nested to render properly; consider increasing `max-specpdl-size'")
> KY>       else ...))
>
> it should ask the user "Should we try 15 levels deeper? y-n
>
> and if that is still not enough,
>
> it should ask the user "Should we try 25 levels even more deeper? y-n
> ...
>
> Why?
>
> Because the user is facing a probably one-time bad html message.
>
> He doesn't want to change his .emacs to always let them pass.
>
> He also wants the choice:
> no I don't want to go deeper for this promotional coupon.
> yes my grandmom sent me this so I want to see it.

On the other hand, if you say go deeper too far Emacs will crash.  It's
a bit hard to predict how far is too far, so I'm not sure if this prompt
is such a great idea.  See Bug#16999 "calc crashes when computation
limit is increased" for an example of such a prompt.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16999




This bug report was last modified 7 years and 130 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.