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

Previous Next

Full log

Message #92 received at 66750 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: acorallo <at> gnu.org, 66750 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 acm <at> muc.de, stefankangas <at> gmail.com
Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda
 form as value
Date: Thu, 02 Nov 2023 15:50:14 +0200

> Date: Thu, 2 Nov 2023 11:52:45 +0000
> Cc: monnier <at> iro.umontreal.ca, 66750 <at> debbugs.gnu.org, acorallo <at> gnu.org,
>   stefankangas <at> gmail.com, acm <at> muc.de
> From: Alan Mackenzie <acm <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.