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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> > 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.

> 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.

>> .... 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,
so it's code we already have and use.
The "en masse" doesn't make it complex.


        Stefan