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

> The problem that has thrown me is the use of the doc string in oclosures
> for other purposes.  For example, in position 2 of a lambda form,
> appears something like
>
>     (:documentation 'oclosure-accessor)

Hmm...

> ..  My current code is expecting, on encountering (:documentation ...),
> for the cadr to be a string,

`:documentation` is supposed to be followed by an expression (whose
evaluation should usually return a string, although indeed we abuse it
in the case of OClosures to return a symbol instead).

Regardless of OClosures, the `cadr` of a `:documentation` will very
rarely be a mere string since you don't need `:documentation` when the
docstring can be written as a literal.

> onto which it can add a concat form which
> will prefix the position information.

For the non-OClosure case you should be able to use the equivalent of:

    (:documentation
     (concat <YOURINFOHERE> <THEORIGINALEXPRESSIONHERE>))

is that what you mean?

> A solution to this problem would be to move the above symbol to element
> 2 of the list, something like
>
>     (:documentation nil 'oclosure-accessor)

Here you're talking about the source code, right?
I think the question is rather what representation to use in the values:
OClosures store their type name (symbol) in the slot that normally holds
the docstring, so I think the best short term answer is to say that
OClosures aren't supported by your new feature.

OClosures are a mix of functions and structs, so while it would be
nice to make them enjoy your new feature, I think it's perfectly OK
to say that in this respect they're more like structs than like
functions.
Also they come with more introspection features than normal
functions, so it's usually easier to figure out where they come from
(you can find their type, and then look for the `oclosure-lambda`s
which built OClosures of this type.  For most OClosure types, there's
only one such lambda anyway).

> , so that my new code could place its information in the now vacant
> position 1, giving something like
>
>     (:documentation ";POS\36\0\0\0 [ .... ]\n" 'oclosure-accessor)
>
> ..  What do you think of this idea, and have you any better ideas for a
> solution to the problem?

If it works it might be a good option.  I don't know how this turns into
when we build the corresponding bytecode object, so it's hard to judge.


        Stefan