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

[Stefan Monnier]

>> 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".

>> 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.

>> ??
> 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.

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

Any concrete evidence to back this claim?

>>     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?

> 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.

> 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.

>> 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.

>> 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.

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.

>> [ 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.

> 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.


        Stefan