Re: The poor quality of Emacs's backtraces

[Alan Mackenzie]

Hello, Mattias.

On Thu, Jul 13, 2023 at 16:57:52 +0200, Mattias Engdegård wrote:
> 13 juli 2023 kl. 15.35 skrev Alan Mackenzie <acm@muc.de>:

> >    (wrong-type-argument listp
> >                         #[257 "\300\211\2!\262\1\207" [yes-or-no-p] 4
> >                               "\n\n(fn ARG124 &optional)" t])

> > So, this says that _something_ wasn't a list, without telling me what the
> > something was.

> Actually it does. It's the element after the type, in this case the
> byte-compiled function #[257 ...].

You haven't grasped my point.  It doesn't tell me which variable had
or which evaluation resulted in that invalid value.  It just prints out
the value, leaving me to guess what, exactly, had that value.  Such
"guessing" can take hours or days.

> > It says "wrong-type-argument", but doesn't say why it's wrong.  It
> > doesn't disclose which primitive detected the fault, though Emacs could
> > easily do this.

> Usually it's the topmost function in the traceback.
> If not, please report it as a bug. There's certainly work to be done.

I found the bug, eventually.  I'd written (nth 5 byte-code) where what I
needed was (aref byte-code 5).  If the message had included the
information "nth" in it, I would have found the bug quickly.

> > test suite truncating every line at ~70 characters.  (Why is this done?)

> I agree, that's annoying. We have to truncate at some point or we'll
> be treated to dumps of impractical size before we know it, but 70
> chars is pretty useless.

> > (The symbols in braces are an enhancement I'm currently working on to give
> > more information for anonymous functions.)

> Keep us in touch, because it's very likely that some of us are working
> on the same code, with similar but different goals. Don't go it alone.

You're working on something similar, too?

My enhancement is to store the @dfn{defining symbol} of anonymous
functions inside the function, whether an interpreted function, or
either type of compiled function.  This symbol is the defun/defmacro
etc. within which the lambda is defined.

It's approaching the point at which it would be sensible to create a new
branch for it and commit the changes to it.

> > It's worth pointing out that there doesn't seem to be a way to get Emacs
> > to disassemble a function, only a symbol with a function value.

> Actually there is. Just use the function `disassemble`:

> (disassemble #[257 "\300\211\2!\262\1\207" [yes-or-no-p] 4 "\n\n(fn ARG124 
> &optional)" t])

Ah!  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).