bug#66750: Unhelpful text in C-h v for variables with a lambda form as value

[Stefan Monnier]

> But it's not quite so simple as all that.  In order to get the doc
> strings for lambdas into the .elc file, there'll have to be an
> enhancement of the .elc format.  Currently, although doc strings for
> defuns/demacros/etc. are stored as file name + offset, those for
> lambdas (which are vanishingly rare at this point) are just stored
> inline in the .elc, and would get loaded along with the lambdas.

Yes, I know.  I think it's an orthogonal issue.  It's OK.

Note: I have(had?) a local patch to use (FILE . OFFSET) for local
lambdas' docstrings as well.  I never pushed it to `master` because it
relied on a change in the `prin1` function (basically provide some way
for `prin1` to generate the "#$" string in its output) and I couldn't
think of a way to do that that wasn't too hackish to be worth the
trouble for the "vanishingly rare" local lambdas with docstrings.
[ And also, it broke the make-docfile code that scraped `.elc` files
  because it moved the docstrings a bit, but that's not an issue any more
  because we don't scrape `.elc` files any more.  ]

But if those become more common, the tradeoff would justify getting such
a change in `master` (especially since IIRC it simplifies `bytecomp.el`
a bit).

>> The one thing I'd point out is: try to pick a format for the "data in
>> docstring" that is easily/naturally extensible (contrary to what I did
>> for the arglists), so that when we get around to adding support for
>> things like debugging info we could add it there without having to
>> invent a new format.
>
> I intend to go for simplicity here.

+1

> A signature at BOL

+1

> followed by space separated info fields in a fixed order.

I'd have gone with "a `read`able sexp" so you don't need to write any
new parsing code and it naturally extends to "arbitrary" content.


        Stefan