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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan, Stefan and Eli.

On Thu, Nov 02, 2023 at 14:44:28 -0700, Stefan Kangas wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > On Thu, Nov 02, 2023 at 15:50:14 +0200, Eli Zaretskii wrote:

> >> How about if you propose a compromise with which you could live?

> > That is difficult.

> Thanks for persevering despite the difficulties.

:-)

> I have just now reviewed this thread in full, and I reread also the
> beginning of the discussion.  The contention here is not around the
> general idea, which everyone seems to find more or less useful, but some
> of the design decisions in the proposed implementation.

Or, more precisely, the design decisions in the actual implementation.

> > I could see myself replacing the defining symbol with FILE:POSITION
> > information, but I doubt that would make the two of you happy enough.
> > Or, maybe put this defining symbol or F:P information into the doc
> > string somehow (including in the interpreted format) like Stefan was
> > suggesting recently.

> If I understand you correctly here, you are willing to consider using
> FILE+LINE+COL instead of defining symbol, ....

or possibly as well as it.  Or possibly a character offset in the file.

> .... and storing the information in the docstring instead of the
> lambda form.

In the doc string _inside_ the lambda form.  Its first line could be,
for example, a space separated structured line containing a
characteristic introduction (like we have in .elc files), the source
file, line number, column number, maybe the buffer it came from
(optional), maybe a defining symbol (optional).  This line needn't be
displayed by the help system, and could be as long as needed.

> And if I understand Stefan Monnier's argument correctly, it seems like
> he wouldn't object to that.

I hope not.  It is more than a small compromise for me, since the info
will not be stored in RAM as I wanted, and also I'll have to start work
on it again from scratch (but with the benefit of experience from doing
it the first time).  It is a compromise for Stefan M and Eli, since it
would enable the mechanism to work for interpreted functions, too.

How do you feel about this, Stefan (M.)?

> So why not proceed along those lines?

I'm willing to do this.  I hope you (Eli) will find it OK, too.

-- 
Alan Mackenzie (Nuremberg, Germany).