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

[Eli Zaretskii]

> 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?

> 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.

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

> > 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.

> > Anonymous lambdas come as a very distant second or third problem, at
> > least IME.
> 
> They've been a problem for me, at least.  That's why I set about solving
> it.  And being of a lower priority is no reason to reject an existing
> fix.

You know very well that priority is not the reason we are arguing.
There's no need to bring up irrelevant side-tracking arguments, it
doesn't help in any discussion, and more so in this one.