From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Date: Mon, 30 Oct 2023 09:44:54 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4882"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66750@debbugs.gnu.org, Andrea Corallo , Stefan Kangas , acm@muc.de To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 30 10:45:53 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qxOqH-00019c-2h for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Oct 2023 10:45:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qxOpv-0008GW-OQ; Mon, 30 Oct 2023 05:45:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qxOpt-0008GN-U9 for bug-gnu-emacs@gnu.org; Mon, 30 Oct 2023 05:45:29 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qxOpt-0007aQ-MB for bug-gnu-emacs@gnu.org; Mon, 30 Oct 2023 05:45:29 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qxOqP-0007KV-UN for bug-gnu-emacs@gnu.org; Mon, 30 Oct 2023 05:46:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Oct 2023 09:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66750 X-GNU-PR-Package: emacs Original-Received: via spool by 66750-submit@debbugs.gnu.org id=B66750.169865913728134 (code B ref 66750); Mon, 30 Oct 2023 09:46:01 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 30 Oct 2023 09:45:37 +0000 Original-Received: from localhost ([127.0.0.1]:44249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qxOq0-0007Jf-S5 for submit@debbugs.gnu.org; Mon, 30 Oct 2023 05:45:37 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:15517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qxOpy-0007JN-6W for 66750@debbugs.gnu.org; Mon, 30 Oct 2023 05:45:36 -0400 Original-Received: (qmail 68885 invoked by uid 3782); 30 Oct 2023 10:44:55 +0100 Original-Received: from acm.muc.de (pd953a35e.dip0.t-ipconnect.de [217.83.163.94]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 30 Oct 2023 10:44:54 +0100 Original-Received: (qmail 14197 invoked by uid 1000); 30 Oct 2023 09:44:54 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273544 Archived-At: 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).