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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Nov 02, 2023 at 08:13:30 +0200, Eli Zaretskii wrote:
> > Cc: 66750@debbugs.gnu.org, Andrea Corallo <acorallo@gnu.org>,
> >  Stefan Kangas <stefankangas@gmail.com>
> > Date: Wed, 01 Nov 2023 18:46:24 -0400
> > From:  Stefan Monnier via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>

> > >> Before catering to the same use-cases as early-debug, we should cater to
> > >> the use cases of the average user/developer who's never getting close to
> > >> the bootstrap.
> > > I disagree.  I don't understand why you want to split off (some of) "the
> > > use cases of the average user" and only handle those cases.

> > I don't.  Instead I'm saying we should first and foremost design the
> > functionality for the most common case.  And *then* see what it takes
> > to extend it to other cases.

> Agreed.

What Stefan seems to be proposing does not accord with his previous
paragraph.  He is proposing an implementation which would preclude
extension to what he calls the "less common" cases - things like working
in edebug and interpreted code in general, amongst others.

> Alan, we are in the engineering business, where designing for the most
> common case, before adjusting the design in small ways for less common
> cases, is one of the important principles.

Another principle is not closing off future options.  Stefan wants partly
to implement this feature in a way which could not be extended to
interpreted code, I think.  He has not given any indication of having
thought about a mechanism to do this; just "we can think about that
later, perhaps".

We're at the stage where there's working code, which already works for
edebug, ERT backtraces, early-debug.el, and so on.  So why are we
debating abstract design principles?

> > > My intention is to handle _ALL_ cases, and you find this objectionable
> > > for some reason.

> > Because your focus on the fringe cases has negative impacts on the
> > more common case.

What are these negative impacts?

Stefan has alleged negative impacts, but has not done any measurements to
demonstrate them, as far as I can make out.

> And this is the usual outcome of trying to solve _ALL_ cases from the
> get-go, by focusing on the fringe ones.  Premature optimization and
> all that.

I haven't focussed on fringe cases.  I've focussed on getting a uniform
implementation without special cases.  It hasn't been easy, but I think
I've succeeded.

It would be nice if people actually tried out the code in practice before
criticising.  So far, there's no indication anybody has done this.

> Alan, I'd appreciate if you rethink your approach to the
> implementation with the above principles in mind.

I don't want to implement something which will only work most of the time
for the easy to implement cases, and which precludes extension to the
general case.  I'd welcome any suggestions for a mechanism which would be
capable of extension to the general case.

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

Debugging Emacs Lisp is frequently a horrible experience, with partial
error messages which don't tell you exactly where an error occurred,
don't tell you which primitive triggered an error, and frequently give
truncated backtraces, if any at all, due to unwise condition-cases, and
so on.

One of these things is having meaningless anonymous entries in
backtraces and C-h v, with no connection back to the source code.
feature/named-lambdas fixes this.

-- 
Alan Mackenzie (Nuremberg, Germany).