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

[Alan Mackenzie]

Hello, Andrea.

On Wed, Oct 25, 2023 at 16:53:38 -0400, Andrea Corallo wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Emacs.

> > Supposing a variable has as a value a lambda function.  On doing C-h v
> > for this variable, there ensues a useless lack of information about the
> > lambda.  All one gets told is that it is a lambda function, not where the
> > source code for it is, or anything useful like that.

[ .... ]

> > #########################################################################

> > I see two ways to fix this bug:
> > (i) Systematically to replace each of these lambda functions by a named
> >   defun.
> > (ii) To adopt git branch feature/named-lambdas, which attaches to every
> > lambda function the name of the defun (or defvar) in which it was
> > defined.  This extra information could then be printed out for C-h v,
> > something like this:

> >     Its value is
> >     {isearch-fold-quotes-mode} #<subr 
> > F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109>
> >     Original value was nil
> >     Local in buffer *info*<3>; global value is nil

> > , thus enabling the user quickly to locate the source of the lambda form
> > in isearch.el.

> Hi Alan,

> what (if any) do you think are the downsides of option ii?

Currently feature/named-lambdas is mostly working, not fully working.
Probably the most pressing of these deficiencies is that native compiled
lambda functions don't yet get their defining symbol set.

There have been substantial amendments compared with the master branch,
and it has not been tested much by anybody but me.

Assuming it can be brought to a fully working state, there would be an
extra symbol in each function definition which would make Emacs
marginally bigger.

> Thanks

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).