bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#67455: (Record source position, etc., in doc strings, and use this i


From: Alan Mackenzie
Subject: bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.)
Date: Sat, 30 Mar 2024 09:10:14 +0000

Hello, Stefan.

On Thu, Mar 28, 2024 at 12:25:11 -0400, Stefan Monnier wrote:

[ .... ]

> >> The earlier the better, in theory, but not at any cost.
> > No, the earlier the better, full stop.

> Please "full stop" being absolutist.  We're talking about opinions and
> preferences here.

What you're proposing is only handling some fuctions because you think
we're collectively not clever enough to maintain
byte-run--posify-defining-form.  This would leave Emacs inconsistent,
some functions failing to be handled not for any functional reason, but
because of an alleged lack of our capability.

> When hitting an error, I spend more time reading the code (and modifying
> it) than looking at debug output, so to me the clarity of the code is
> more important than whether a few lambdas get some addition positional
> info, especially since I usually know full well where those lambdas
> come from.

My prime method of debugging is reading code, too.  But you're conflating
the clarity of b-r--p-defining-f with the clarity of the code you're
debugging.  They're different things.  The former is less important than
the latter.  The whole point in these changes is to give info precisely
in those anonymous lambda entries in backtraces which currently contain no
information.

> I understand it affects us differently, but the tradeoff is real.

> >> Having to write all that code within the very restrictive sublanguage
> >> available before subr.el and backquote.el is a cost I don't think
> >> justifies it.

This is done in other functions, too.

> > The cost has already been paid, by me.

> Code is not "fire and forget".

[ .... ]

> >> But your current code in byte-run.el is a Bad Thing as well.
> > What, precisely, do you find bad about it?  It may be possible to improve
> > it without wholesale redesign.

> A lot of it is hard to read because it is constrained to a restrictive
> subset of ELisp.

byte-run--posify-defining-form uses the same techniques as other declare
clause handlers, such as byte-run--set-interactive-only and many others.
Why is b-r--p-defining-f objectionable, but not b-r--s-i-only?

It was tedious rather than difficult to write, and it is tedious rather
than difficult to read.

> >> I'm not suggesting to drop support for lambdas loaded from source.
> >> I'm saying we don't need to support it for the first N files loaded into
> >> `src/emacs-bootstrap`.
> > You're suggesting dropping support for many source files, where that
> > support is most needed.

> "Most needed" according to which criteria?

The difficulty of debugging in early bootstrap compared with when further
debugging tools have already been loaded.

[ .... ]

> Code costs by merely existing.

Inconsistencies and sloppy implementation cost too.

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]