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 12:32:32 -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="5302"; 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 17:33:42 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 1qx8jN-00016b-0E for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Oct 2023 17:33:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qx8jC-0004X4-WF; Sun, 29 Oct 2023 12:33: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 1qx8jB-0004Wv-Ej for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 12:33: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 1qx8jB-0003YN-6d for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 12:33:29 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qx8jh-0007gc-Q1 for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 12:34:01 -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 16:34: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.169859719629483 (code B ref 66750); Sun, 29 Oct 2023 16:34:01 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 29 Oct 2023 16:33:16 +0000 Original-Received: from localhost ([127.0.0.1]:43217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qx8ix-0007fS-FU for submit@debbugs.gnu.org; Sun, 29 Oct 2023 12:33:15 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qx8iu-0007fC-M0 for 66750@debbugs.gnu.org; Sun, 29 Oct 2023 12:33:13 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 49905807DB; Sun, 29 Oct 2023 12:32:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1698597153; bh=eaLvw+C/K2XPfEeUBei/if4jr6Rls/6ct+Zg808iMf4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gYvptijM0UXBWgi2AjTwO41xKGQl3vFJFL8Pgj6rhOTGJTMs7Y6KwDf/d4CTAxHzK UwMji1K25AR0vOOqZk6ibFyfdyxrsAFo5dtp3+SW8FseiZXd5g0/5yfPJACSVuobDh s9gKm6p0GdW8rZJz9aVEbzNn2lCXQ2XRNNXSlWwytUJm8PXkUARb7aMPBVJmRSNFzW ARQTyawHWMd3sKKI58nQZ1qKtbvfsGTT9d1JDHD7h7WuzoLceIbhiDBaRIrO88xHjN GcU5Not9DbRLek8m7XSOxYmxgzoGiii3qSQ5o7gBmkxikgoBs6JY5w7JVFaj8+h5DC Q0PhxrOXl4hLQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4503A80060; Sun, 29 Oct 2023 12:32:33 -0400 (EDT) Original-Received: from pastel (unknown [45.72.195.71]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1563C120377; Sun, 29 Oct 2023 12:32:33 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sun, 29 Oct 2023 11:25:14 +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:273515 Archived-At: >> Hmm... it seems like keeping the LINE+COL info rather than >> a surrounding definition would be better in this regard since it wouldn't >> require any changes at all to the actual lambdas, regardless where >> they are. > I don't agree with this. Whether we add FILE+LINE+COL info is to a > large degree a separate question from that of adding defining symbol > info. It seems to me, if you have one of the two, the other becomes much less important. > If you don't add information to the actual lambda, then that information > won't be available when that lambda turns up in a backtrace or as a > value in C-h v. Surely you'd have to keep FILE+LINE+COL in the lambda > itself, somehow. In the docstring. > It will also stress the user somewhat, since it will force her to look > up a file location to get any idea of what is failing. A defining > symbol is much more immediately useful, even if it may not be 100% > dependable because of the issues you raise below. ?? >> The notion of "surrounding definition" is less precise (there can be >> several lambdas inside a given definition, there can be lambdas outside >> of any definition, ...). > Yes, there can be several lambdas in a function, though I don't think > this is common. You'd be surprised, especially with lambdas introduced by macros. > Certainly it hasn't given me any problems in use, so far. In the past, the byte-compiler only provided the name of the surrounding definition in its warnings. Maybe we should go back to that? :-) > But lambdas outside of definitions? I doubt very much there are > any in the Emacs sources, or even in the packages. grep -C1 '^(add-hook' **/*.el | grep '(lambda' begs to differ. >> 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 ? > For that matter, what are you going to print in that C-h v example? #? Tho we could skip the FILE:LINE and buttonize some part of the string instead, for the `C-h v` case. >> Yup. [ Tho now that you make me think about it, if we want to be cheap, >> we could go to that OFFSET position and look around for a `^(defalias` >> and that might be sufficient to give us "the surrounding definition" in >> many cases :-) ] > That doesn't sound systematic, or at all attractive. ;-) But so much fun! Admittedly, I haven't jumped on this hack because my own local hacks move the docstrings to the end of the `.elc` files, making this additional hack impossible :-) >> What I meant is that the docstring is in the `.elc` file. So the >> bytecode object would be literally unchanged, it's just that the >> bytes found at OFFSET inside FILE would be extended to hold: >> - the docstring >> - the human-readable arglist >> - the LINE+COL info > > Don't forget, all this info would have to go into .eln files too, > probably in the struct Lisp_Subr. 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. 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". > It would be better if it were also somehow available in uncompiled > lambdas, something which is needed for debugging failures in > early bootstrapping. Yeah, "WIBNI", but as I said, when you have an uncompiled lambda, the content of the body is usually sufficient to manually find the matching source. So I think we should focus on the compiled case first and then maybe consider how or if we can/should extend it to the uncompiled case. [ 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. ] Stefan