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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 66750 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value
Date: Fri, 03 Nov 2023 18:18:08 -0400

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.