Re: Recursive Fload and eval-after-load forms. (See bug #43116.)

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Mon, Aug 31, 2020 at 23:18:35 -0400, Stefan Monnier wrote:
> > Fload bails out with an error if the nesting of files it's loading has
> > a file more than three times in the stack.

> Indeed, we know that recursive loads do exist and don't always end up
> inf-looping, so we only signal an infinite recursive load when it looks
> *really* bad ;-)

> > Maybe instead we could modify custom-menu-create such that it will only
> > require its target file if that file isn't currently being loaded.

> We could try that.  Or we could make it return a dynamic menu whose
> content is only computed when the menu is actually displayed.

> > If it is currently being loaded, then we only include the customisable
> > variables that have already been defined.  This shouldn't be too much
> > of a hardship, since custom variables tend to be defined near the
> > start of a .el file, and the higher level functions which create the
> > custom menu tend to be nearer the end of the file.

> > What do you think?

> According to `grep` it would be good enough for the 3 use cases we have
> bundled with Emacs.

Something like:


diff --git a/lisp/custom.el b/lisp/custom.el
index 885c486c5e..f8e154e7ae 100644
--- a/lisp/custom.el
+++ b/lisp/custom.el
@@ -649,7 +649,8 @@ custom-load-symbol
       (ignore-errors
         (require 'cus-start))
       (dolist (load (get symbol 'custom-loads))
-        (cond ((symbolp load) (ignore-errors (require load)))
+        (cond ((being-loaded-p load))   ; For bug #43116
+              ((symbolp load) (ignore-errors (require load)))
 	      ;; This is subsumed by the test below, but it's much faster.
 	      ((assoc load load-history))
 	      ;; This was just (assoc (locate-library load) load-history)


, where `being-loaded-p' would be a new primitive in lread.c which would
just scan the static variable Vloads_in_progress with Fmember.  Of
course, some doc strings would need amendments, too.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).