bug#55414: 29.0.50; Byte compilation error for the modus-themes

[Alan Mackenzie]

Hello, Eli.

On Mon, May 16, 2022 at 15:26:57 +0300, Eli Zaretskii wrote:
> > Date: Mon, 16 May 2022 12:03:05 +0000
> > Cc: larsi@gnus.org, info@protesilaos.com, 55414@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > If this compilation succeeds, then perhaps we need to increase our
> > > > default max-lisp-eval-depth.

> > > But do we need to do that by default in Emacs, when the problem is
> > > local to this theme?  Can't the package arrange for enlarging the
> > > threshold only for itself?

> > We could.  But I get the feeling that there are quite a lot of places
> > which increase max-lisp-eval-depth for their own use.

> Examples of those places?

OK, i've kind of conflated max-lisp-eval-depth with max-specpdl-size, as
they seem to be the same sort of thing.

In recent months I've increased max-specpdl-size to 5000 in
emacs-lisp/comp.el, and also to 5000 (default is 2500) in
leim/Makefile.in for the generation of leim-list.el.  Also
max-specpdl-size to 5000 in admin/grammars/Makefile.in.

With a bit of grepping, max-lisp-eval-depth is increased in edebug.el,
regexp-opt.el, gnus-sum.el, ....

So, apologies, I was thinking more about max-specpdl-size.  But surely
the default values of both these variables should be sufficiently large
to handle almost any evaluation, with only the rarest/most specialised of
evaluations needing them increased.

> > Put another way, is there any overwhelming disadvantage to having a
> > larger default value of max-lisp-eval-depth, and possibly
> > max-specpdl-size?

> The disadvantage is that higher values prolong the time needed to
> detect real infinite recursions, and enlarge the probability of
> hitting C stack overflows, whose consequences are much more serious
> and harder to endure without losing the session and its edits.

Yes.  I seem to remember the Elisp manual saying only that these values
can be increased considerably without danger.  Or something like that.
Perhaps we should be a little less vague on this point.

-- 
Alan Mackenzie (Nuremberg, Germany).