bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.)

[Stefan Monnier]

>> The point is that `byte-compile-in-progress` will be non-nil during
>> those loads, so you can't use this variable to get the information you need.
> Yes.  How about binding it to nil around `load' and recursive edits, and
> possibly one or two other things?

You mean trying to enumerate all the places we can think of where we
know that compilation is not taking place?  That sounds rather ugly.
I'd rather first try and define precisely what is we mean by
"compilation in progress".

I see the same problem with:

      DEFVAR_LISP ("defining-symbol", Vdefining_symbol,
               doc: /* The symbol currently being defined by a defining form.
    This variable is bound in the read-eval-print loop and certain
    high-level functions in the byte compiler.  It is set to a value by
    functions and macros such as `defun', `defmacro', and `defvar'.  */);

Lots and lots of things can happen "during the definition" of a form,
including definition of lots of other forms.  So I think we'd need to
define much more precisely what you meant by "currently".
In addition, a definition is "intemporal" (it's declarative), so
"currently being defined" is almost like an oxymoron.

I'm trying to understand your code, but I clearly lack a high-level
overview of the approach you decided to takes, so I don't understand
what's going on there.

Is that branch trying to provide function-position for compiled
functions only, for interpreted functions only, or both?

If both, could you split it into two, then?
AFAICT doing it only for compiled functions should be significantly
simpler than for interpreted functions, so it would be a good
stepping stone.

On the cosmetic side, you have way too much code in `byte-run.el`.
I think most of this code can be moved elsewhere, e.g. somewhere where
backquote can be used


        Stefan