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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Oct 29, 2023 at 17:47:57 -0400, Stefan Monnier wrote:
> >> It seems to me, if you have one of the two, the other becomes much less
> >> important.
> > True, but still important nevertheless.

> Not in my opinion.  We've lived with neither for the last 40 years and
> it hasn't been raised as a problem pretty much ever during those 40
> years, so anything that covers the 90% cases will be already borderline
> "overkill".

Debugging Emacs Lisp is, in my experience, a ghastly task - incomplete
error messages, incomplete backtraces (largely due to unneeded
condition-cases), inability to run a debugger on redisplay hooks, ....
This latest amendment of mine is one small element of making it less
ghastly.

> >> In the docstring.
> > But the docstring isn't in the lambda at the moment.  There's merely a
> > pointer to it there, which is no good for backtraces - it's too fragile.

> Never had a problem with that.

Not yet.  Putting complicated stuff into backtrace code is a bad idea -
look what happened when cl-print got put into debug-early.el.  Bugs.

> > Dealing with backtraces is a stressful business.

> I think you're going to give more concrete details if you want to
> convince me of that.

Don't be silly.  Any time there's a backtrace, somthing Has Gone Wrong
and Isn't Working.  That's bound to raise stress levels.

> > Forcing a user to look somewhere else for pertinent information can
> > only increase that level of stress.

> Any concrete evidence to back this claim?

Of course not.  Just as you've got no evidence to back up the contrary.

> >>     grep -C1 '^(add-hook' **/*.el | grep '(lambda'
> >> begs to differ.
> > OK, good point!
> > Here, obviously, the hook symbol should become the defining symbol,

> So that when you look at the functions on SOMEHOOK wondering where they
> came from, they'll tell you "oh, I come from SOMEHOOK"?

> > though admittedly this isn't coded up, yet.

> Not sure it would be very useful either.

> >> >> Furthermore, that info is already available to the bytecompiler, so it's
> >> >> actually easier to keep that info.
> >> > How are you actually going to use this information?  What are you going
> >> > to print in a backtrace, in particular in a batch mode backtrace where
> >> > things like buttons are not useful?
> >> FILE:LINE ?

> > That is anything but concise, in contrast to printing the defining
> > symbol in braces.  I've just had a look at a bytecomp.elc, and the
> > filename in the docstring field is 67 characters long.

> Hmm... have you ever seen the FILE info we print in `C-h v`?
> Has it often reached 67 chars?
> Then why do you presume we'd be so stupid as to include the full
> absolute file name in there?

That falls outside the bounds of acceptable GNU mailing list language.

> > In anything short of a full screen Emacs window, this, together with
> > the name of the subr, is going to spill over onto the next line.

> Yes, if we try hard enough, we can fuck things up badly, of course.

So does that.

> > Besides which, you'd need to store all the pertinent information, the
> > filename + line + column in RAM, probably in the subr or the byte
> > coded function.

> I already told you where we'd store that info.  Not in RAM.

So with all the extra complexity you want to add, you'll risk getting a
recursive error and recursive backtrace.

> >> That's the beauty of it: by storing the info inside the raw docstring,
> >> we get to reuse all the existing code that takes care of storing the
> >> docstring somewhere.
> > Making another non-obvious structure to compete with the (lexical)
> > parameter specs.

> Yes.  Hopefully fixing that arglist thingy along the way.

> > As I keep on saying, a backtrace may not depend on reading files;

> Saying so doesn't make it true.

You haven't made any attempt to justify this, to my mind, questionable
design.

> >> Also, the "performance profile" of docstring matches our needs here:
> >> just like docstrings, we don't need FILE+LINE+COL info under normal use,
> >> it's only needed when developing/debugging, so we want to store it "out
> >> of line".
> > Disagree: anybody getting a backtrace, or looking up a variable with C-h
> > v needs this information, at the very least for including in a bug
> > report.  ;-)

> IOW, you agree.

> > We cannot ignore it, push it down the road, and hope that somehow it
> > can be tacked on later.

> Of course we can, because we don't *have* to instrument it.

Which looks like you intend to strip it out, leaving interpreted code as
a special case without the instrumentation.  I don't think that's a good
idea.

> No matter how hard we work at it, there will be cases where "the origin"
> of an anonymous function will be anything but obvious.  Even if we can
> pinpoint the source code where the `lambda` itself is found, it may be
> of no use to the programmer trying to figure out where it really "comes
> from".

> So it'll always be a best effort, where we try and cover the important cases.

Which is a good deal better than the current state of affairs.

> >> [ And, yes, if we really want to, I think we can add the FILE+COL info
> >> to uncompiled lambdas: it would force us to read `.el` files "with
> >> sympos" (thus slower) but it shouldn't be hard.  ]
> > Again, there must be no file reading when constructing a backtrace.

> I'm not talking about `read`ing when you try and display the lambda.
> I'm talking about `read`ing where you `load` the code that will evaluate
> that lambda.

You've been anything but clear in saying what you intend here.  You've
talked about "in the doc string" without saying whether you meant in the
..elc file or in the loaded program, for example.  That's a critical
difference.

> > I still believe that the defining symbol scheme is the most practical
> > way of conveying the needed extra information to the user.

> Obviously.

> > Otherwise I would have hacked something different.  ;-)

> I don't think that's how it works, sadly.

What are you talking about with "that"?

Thus far, all you've done is disparage every design decision I've made
with this code, saying how you would have done it differently, without
giving any justification for why your way would be better.  How am I
meant to react?

Thus far, you've given no sign that you've actually tried the code out,
or done anything else with it bar vaguely looking at a diff from master.
It would be nice if you were actually to evaluate this code.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).