From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Date: Sun, 29 Oct 2023 17:47:57 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37006"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66750@debbugs.gnu.org, Andrea Corallo , Stefan Kangas To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 29 22:48:49 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 1qxDeL-0009Oi-0u for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Oct 2023 22:48:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qxDe5-0000FT-30; Sun, 29 Oct 2023 17:48:33 -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 1qxDe2-0000Eu-SF for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 17:48:30 -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 1qxDe1-0004Bi-PI for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 17:48:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qxDeY-0004nD-H3 for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 17:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Oct 2023 21:49:02 +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.169861612418306 (code B ref 66750); Sun, 29 Oct 2023 21:49:02 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 29 Oct 2023 21:48:44 +0000 Original-Received: from localhost ([127.0.0.1]:43620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qxDeG-0004l7-0s for submit@debbugs.gnu.org; Sun, 29 Oct 2023 17:48:44 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qxDeE-0004kH-9E for 66750@debbugs.gnu.org; Sun, 29 Oct 2023 17:48:42 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8E076100061; Sun, 29 Oct 2023 17:48:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1698616078; bh=r0DOHOdnobdwGFawlvUSas6UUSL1jDJB1WXudTVPbTM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XvT3bddh76qATpfWrKSjzHEnqFmcJU5muf66iU//+apOwSuECqVXmSCO6iNamXJ+Z uDQO/CRmSWDrYgWNqklM7yiak8gamsB90GyabF+ayYBlW8cbATwsY5izplRs5ePJwH zBu8+tWbTqJinwayzJL4xZcp8cYrDO/93OJl0WOr5QZ+luXCkpNeQFUIR3JWBGpZ6p +4ASxvN1jhigMHmmpGABv+jWYlBcS98shG4tIQ5/TdMloJtasDjUORsWsUsPAUjLp1 Jpp9oq/NqUSToIMLG/4Z7+TYWTDPveVJc2UaHe+YVr0mZFCJyJchRawU4RXr0ZkHf8 pcM4W8gPjgpFw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 54037100068; Sun, 29 Oct 2023 17:47:58 -0400 (EDT) Original-Received: from pastel (unknown [45.72.195.71]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2431812025A; Sun, 29 Oct 2023 17:47:58 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sun, 29 Oct 2023 18:50:34 +0000") 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:273528 Archived-At: >> 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