bug#66912: With `require', the byte compiler reports the wrong file for errors.

[Stefan Monnier]

> There needs to be some mechanism for resetting this variable to Qnil,
> should the error handler fail to access it.

I was thinking we wouldn't bother, just like the we don't bother
emptying the match-data after we used it.

> Also, we need to be careful about condition-cases in debuggers, where an
> error, even if handled, might overwrite Vloads_in_progress_of_last_error.

Yes, we may want to locally let-bind the var to preserve it, similarly
to the occasional use of `save-match-data`.

> However, signal_or_quit is supposed to be a general low-level function,
> and it doesn't seem ideal to bloat it out with special purpose tests.

Indeed, which is also why I was pointing out that the thing could be
generalized to other context information, so we don't get fixated on `load`.

> Another possible problem with this wild idea is that debuggers, or parts
> of them, might need to be autoloaded.  This shouldn't be a problem with
> edebug.el, where the file would be loaded to be able to instrument a
> form, but I don't think anything's loading debug.el before it gets used.

If the let-binding that preserves the new var is performed around the
call to the debugger (rather than being performed inside the debugger
itself), we should be OK.

> I think your idea might be better than my current patch, but I doubt
> it's going to be much simpler.

The thing I like is that it should be a better replacement for
`Vsignaling_function` (which is currently a very low-tech feature which
works only half the time).

>> > I think I would agree, but this would be difficult for .el[cn] files.
>> > How about giving the line number just for .el files, something like:
>> That's what I meant, yes.
> OK, I'll think about that, but after we've got the basics (see above)
> sorted out for this bug.

Yes, there's no hurry.


        Stefan