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

From: Stefan Monnier <[email-masked]>
Date: Tue, 26 Mar 2024 15:40:05 -0400

>> >> > Sorry about that.  A quick summary: defined symbols (and lambda) get
>> >> > positioned by the new reader function read-positioning-defined symbols.
>> >> > The new declare clause defining-symbol marks a macro such as defun or
>> >> > cl-defgeneric as a macro which defines such symbols.
>
>> Since I still don't understand the general picture, let me tell you how
>> I would plan to do it, so you can tell me where it matches your
>> approach and where it doesn't:
>
>> - Change `load-source-file-function` so it uses
>>   `read-positioning-symbols` instead of plain `read`.
>>   [ This means that macro-expansion will now almost always have sympos,
>>     rather than only during compilation,  ]
>
> load-source-file-function is set to read-positioning-defined-symbols.

[ I see it's `load-read-function`.  ]

How does this differ from `read-positioning-symbols` and why do we need
it to be different?

> (In a change to be committed, it gets bound to this function in Fload).
> In reading
>
>     (defun foo () "foo doc" (lambda (bar) "lambda doc" (car bar)))
>
> , foo gets positioned (because it follows defun), and so does lambda
> (because it is a lambda following "(").

IIUC "gets positioned" means that it is a symbol-with-pos rather than
a bare symbol?

> I'm not entirely sure, but I think in non-eager macro expansion the
> position information in SWPs is typically available.

In lazy macro-expansion, SWPs are not available, no.
But that's OK, it's rare and there's very little we can do about it (the
reason it's lazy is indeed because we only discover very late that those
sexps were meant to represent code.  It's typically when a sexp is
passed to `eval`).

        Stefan