bug#683: 23.0.60; Recursive load error stays

[Juanma Barranquero <lekktu@gmail.com>]

On Tue, Aug 26, 2008 at 05:37, Markus Triska <markus.triska@gmx.at> wrote:

> Yes - it works as I expect when I quit the debugger with "q", but not
> within the recursive edit (i.e., if I leave the *Backtrace* buffer open
> and do not exit the debugger). Other forms seem to evaluate as usual
> also in the recursive editing level, whereas "load" seems different.

For starters, using C-x C-e inside a comment is a bit weird; it
"works", for single-line expressions, but it uses forward-sexp, whose
docstring says: "This command assumes point is not in a string or
comment."

That aside, what happens is this: `load' uses a static variable
Vloads_in_progress to detect recursive loads. On the normal (not
backtrace) case, *before reading the file*, it checks the name of the
file against Vloads_in_progress, finds nothing unusual, so it loads
the file (by calling the Vload_source_file_function).

In the backtrace case, when trying to load ~/p.el again, load is still
on the call stack, so Vloads_in_progress has not been reset to nil; as
expected, `load' finds p.el in Vloads_in_progress, and bails out. It
is irrelevant whether you commented out the line and saved the file,
because it is not being read yet at that point. If you try to load
another file instead you'll see it loads OK, because it is not in
Vloads_in_progress.

It is not a bug: calling a function when it is in the call stack will
be affected by global variables and other non-reentrant code used in
that function.

    Juanma