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

[Alan Mackenzie]

Hello, Eli.

On Thu, Nov 02, 2023 at 15:50:14 +0200, Eli Zaretskii wrote:
> > Date: Thu, 2 Nov 2023 11:52:45 +0000
> > Cc: monnier@iro.umontreal.ca, 66750@debbugs.gnu.org, acorallo@gnu.org,
> >   stefankangas@gmail.com, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

> > > > I think you've already decided not to merge feature/named-lambdas.  I'm
> > > > not surprised, but it's a shame.

> > > I didn't yet make any decision, because I still hope you will agree
> > > with at least some of the arguments.  Or at least agree to some kind
> > > of compromise, even if you keep your opinions.

> > I don't think Stefan is talking about a compromise.  He's talking about
> > discarding my changes entirely, and starting again from scratch, working
> > to design principles and with design goals I disagree with.  How is that
> > a compromise?

> > Or had you in mind something less drastic?

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

That is difficult.  What you and Stefan are objecting to is not the minor
details of my patch, it's its very essence.  That essence is the
existence of the defining symbol, and the amendment of the three function
formats to accomodate it.  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.

> > A couple of days ago I got the error message:

> >     emacs-lisp/eieio.el:55:2: Error: Wrong type argument: listp, 
> > :autoload-end

> > At the indicated file position there was just a `require' form.  So there
> > was no information about where the error happened, what detected the
> > error, or what function or what variable gave or had the value
> > :autoload-end.  It says little more than "there was an error".  This is
> > what I mean by "horrible".

> This is what I call "debugging".  By and off itself, such a situation
> is not necessarily anywhere near "horrible".  For example, it could be
> that in the 'require'd file you will easily find the reference to
> :autoload-end.

Yes, but it takes an order of magnitude longer than if it had given the
position in the required file where the error happened and had told me
that it was a cadr operation which threw the error.  All these oders of
magnitude longer add up to hundreds of hours over the years.

> I also don't necessarily see how this is relevant to the issue at
> hand.

It's not.  Except it's all part of the same overriding topic, what I feel
to be the inadequacy of Emacs's Lisp debugging tools.

> > > If I have a single significant gripe against Emacs Lisp backtraces, it
> > > is that there's no way of jumping to the offending source line in each
> > > stack frame, something that is very natural to provide.

> > This would be more difficult to implement.

> Maybe so, but if your feature doesn't bring us closer to that goal,
> then for me personally it is much less interesting.

Maybe we could put no-ops into the byte compiled format, where each no-op
had a position argument.  But that would make Emacs a bit slower.  Or we
could add an extra "debugging" field to the structure which would contain
the position information.  As with lots of things, macros would
complicate such a scheme.  In the native compiled format, isn't there
already a standard way of writing this info?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).