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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Wed, Mar 27, 2024 at 08:23:52 -0400, Stefan Monnier wrote:
> >> > r-p-defined-s positions only lambdas and NAMEs defined by defun,
> >> > defmacro, defvar, .... (around 50 defining symbols).  r-p-s positions
> >> > every symbol apart from nil.  They have different purposes.  r-p-d-s
> >> > gets info for the doc strings, which requires SWPs only for some
> >> > symbols.  r-p-s is needed to get warning message locations.  Were r-p-s
> >> > used for the doc string position information, most of the symbols would
> >> > need to be stripped of their positions before the form could be used.
> >> > It is simpler and faster not to position them at all.
> >> In terms of code, I can't see why it'd be simpler: we already have the
> >> r-p-s function, ....
> > We also already have r-p-d-s.

> You're playing on words here: we don't "already have" `r-p-d-s` on master.

I'm not playing on words.  My point is that
read-positioning-defined-symbols exists and works.  It is not a
speculative "would be nice to have".  The work has already been done.

> > Both functions (together with plain read) have read0 as their core
> > engine.  The enhancement to read0 to support r-p-d-s was only moderate
> > in size and not complicated to anybody who understands finite
> > state machines.

> Just because it's not a complex change doesn't mean it's "simpler" than
> no change at all.

No change isn't an option, here.  Something has to determine which
symbols are to be positioned / stripped of their positions.  Currently,
this is done economically in r-p-d-s.

> >> .... and we already have a function to strip that info when we don't
> >> need it any more, so it would be less new code to write if we just
> >> used r-p-s, I think.
> > I think you're envisaging an extensive redesign where SWPs would not be
> > tightly and individually controlled as they are at the moment, but
> > instead would be created en masse and stripped en masse a bit later.

> Yes, that's the starting design I had in mind (and that I described
> a few emails back).  it's also what we do in the byte-compilation case, ...

It's not.  In each case, the optimum number of symbols gets positioned.
Positioning "everything" is sub-optimal for everything bar byte
compilation.

> so it's code we already have and use.

See above.

> The "en masse" doesn't make it complex.

It changes the design extensively, thus introducing new complications.

Why do you think this design change will be better than the existing
design?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).