Received: (at 66750) by debbugs.gnu.org; 29 Oct 2023 11:26:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 29 07:26:00 2023 Received: from localhost ([127.0.0.1]:40550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qx3vb-00051A-VC for submit <at> debbugs.gnu.org; Sun, 29 Oct 2023 07:26:00 -0400 Received: from mail.muc.de ([193.149.48.3]:32619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1qx3vZ-00050u-D4 for 66750 <at> debbugs.gnu.org; Sun, 29 Oct 2023 07:25:58 -0400 Received: (qmail 57970 invoked by uid 3782); 29 Oct 2023 12:25:18 +0100 Received: from acm.muc.de (p4fe15a23.dip0.t-ipconnect.de [79.225.90.35]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 29 Oct 2023 12:25:18 +0100 Received: (qmail 4794 invoked by uid 1000); 29 Oct 2023 11:25:14 -0000 Date: Sun, 29 Oct 2023 11:25:14 +0000 To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Message-ID: <ZT5BGkuX7SJkF5R5@ACM> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> <jwv5y2qr7v8.fsf-monnier+emacs@HIDDEN> <ZT1QIC9T__WSn87L@ACM> <jwvttqapor4.fsf-monnier+emacs@HIDDEN> <ZT1oKMyIxrdF05cj@ACM> <jwv1qdeoz6l.fsf-monnier+emacs@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <jwv1qdeoz6l.fsf-monnier+emacs@HIDDEN> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66750 Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Stefan. On Sun, Oct 29, 2023 at 00:14:24 -0400, Stefan Monnier wrote: > >> > There are lots of detailed changes in eval.c and bytecomp.el (and > >> > friends). Also the macro `lambda' in subr.el has been amended to insert > >> > the current global defining-symbol if there isn't already a non-nil > >> > symbol in that position. > >> So the source code can manually provide this extra symbol in `lambda`? > >> Where have you found that useful? > > The first few functions in debug-early.el and byte-run.el, for a start. > > There, there is not yet a defmacro macro. Also in > > comp-trampoline-compile, where there doesn't seem to be any other way to > > get the name of the primitive into the defining symbol. I think there'll > > be quite a few other places, too. > 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. 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. That also assumes that the source file will be available and unchanged when it's needed. 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. > >> Hmm... as a user, rather than the enclosing definition I think I'd > >> expect to get some kind of source information like FILE+LINE+COL. > > Possibly: either is a good deal better than what we have at the moment. > 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. Certainly it hasn't given me any problems in use, so far. But lambdas outside of definitions? I doubt very much there are any in the Emacs sources, or even in the packages. Or are you thinking about something like an explicit (defalias foo (lambda (..) ...))? > 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? For that matter, what are you going to print in that C-h v example? > >> Actually, the bytecode functions can already keep the FILE info (in > >> the form of the (FILE . OFFSET) cons cell in the docstring slot of the > >> bytecode object), we just opt never to expose that FILE info to the user > >> (we only use it to fetch the actual docstring). > > That's the offset in the .elc file, though, not the source. > 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. ;-) > >> [ Tho, admittedly, it's also that the byte-compiler only uses such > >> (FILE . OFFSET) for named functions, but it wouldn't be hard to change. ] > >> As for how/where to store the LINE+COL, I guess (aref form 5) is still > >> an option, although, maybe we should store that info alongside the > >> docstring, like we already do for the arglist. > > Well, the doc string is at (aref form 4). :-) > 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. It would be better if it were also somehow available in uncompiled lambdas, something which is needed for debugging failures in early bootstrapping. > Stefan -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 29 Oct 2023 04:15:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 29 00:15:10 2023 Received: from localhost ([127.0.0.1]:40066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwxCg-0000u6-8C for submit <at> debbugs.gnu.org; Sun, 29 Oct 2023 00:15:10 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49293) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1qwxCd-0000tW-6V for 66750 <at> debbugs.gnu.org; Sun, 29 Oct 2023 00:15:08 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 91D05807D1; Sun, 29 Oct 2023 00:14:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1698552867; bh=udTIIXgOBnm5Alne1XADhmkL6dNMucBNfr5Y5aXi3Fc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iG4b1u/43bHaby1c+VXaTffP6ZYfc4O8+Iz6wUHfEMrtEVdi1k7RAwYNDozzfApX4 ONxzZtlZ7+ILk3ZEvirqLWaNomZjd7I4u1+4byzzlD1dT6cObybPBpMvGUJBnTF11X OiBRljYR9C1YrYuZS+J8uUkbPwdmKGZYGqxkzHU5RrfW98i73xQuT1P83iwkIcAP29 6Aj6h6U73tUqAV6rM5vEHUkJ60bYCvSF1fxOOOYbCNhhg6NXm72IWnoXzOGpgdo5WI lct/jYvrbU7qwGDNECikc1Wz5aPANw172eJfBgIpcfPu+4IIBjNajwDkG4/QsN7Kgp XBxU+6C4ErxRg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5BB0780060; Sun, 29 Oct 2023 00:14:27 -0400 (EDT) Received: from pastel (unknown [45.72.195.71]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 19F751202CB; Sun, 29 Oct 2023 00:14:27 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Alan Mackenzie <acm@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value In-Reply-To: <ZT1oKMyIxrdF05cj@ACM> (Alan Mackenzie's message of "Sat, 28 Oct 2023 19:59:36 +0000") Message-ID: <jwv1qdeoz6l.fsf-monnier+emacs@HIDDEN> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> <jwv5y2qr7v8.fsf-monnier+emacs@HIDDEN> <ZT1QIC9T__WSn87L@ACM> <jwvttqapor4.fsf-monnier+emacs@HIDDEN> <ZT1oKMyIxrdF05cj@ACM> Date: Sun, 29 Oct 2023 00:14:24 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.001 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66750 Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> > There are lots of detailed changes in eval.c and bytecomp.el (and >> > friends). Also the macro `lambda' in subr.el has been amended to insert >> > the current global defining-symbol if there isn't already a non-nil >> > symbol in that position. >> So the source code can manually provide this extra symbol in `lambda`? >> Where have you found that useful? > The first few functions in debug-early.el and byte-run.el, for a start. > There, there is not yet a defmacro macro. Also in > comp-trampoline-compile, where there doesn't seem to be any other way to > get the name of the primitive into the defining symbol. I think there'll > be quite a few other places, too. 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. >> Hmm... as a user, rather than the enclosing definition I think I'd >> expect to get some kind of source information like FILE+LINE+COL. > Possibly: either is a good deal better than what we have at the moment. 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, ...). Furthermore, that info is already available to the bytecompiler, so it's actually easier to keep that info. >> Actually, the bytecode functions can already keep the FILE info (in >> the form of the (FILE . OFFSET) cons cell in the docstring slot of the >> bytecode object), we just opt never to expose that FILE info to the user >> (we only use it to fetch the actual docstring). > That's the offset in the .elc file, though, not the source. 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 :-) ] >> [ Tho, admittedly, it's also that the byte-compiler only uses such >> (FILE . OFFSET) for named functions, but it wouldn't be hard to change. ] >> As for how/where to store the LINE+COL, I guess (aref form 5) is still >> an option, although, maybe we should store that info alongside the >> docstring, like we already do for the arglist. > Well, the doc string is at (aref form 4). :-) 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 Stefan
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 20:00:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 16:00:17 2023 Received: from localhost ([127.0.0.1]:39598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwpTk-0007px-Mj for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 16:00:17 -0400 Received: from mail.muc.de ([193.149.48.3]:61907) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1qwpTj-0007pk-0K for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 16:00:15 -0400 Received: (qmail 15705 invoked by uid 3782); 28 Oct 2023 21:59:37 +0200 Received: from acm.muc.de (p4fe15319.dip0.t-ipconnect.de [79.225.83.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 28 Oct 2023 21:59:36 +0200 Received: (qmail 20781 invoked by uid 1000); 28 Oct 2023 19:59:36 -0000 Date: Sat, 28 Oct 2023 19:59:36 +0000 To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Message-ID: <ZT1oKMyIxrdF05cj@ACM> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> <jwv5y2qr7v8.fsf-monnier+emacs@HIDDEN> <ZT1QIC9T__WSn87L@ACM> <jwvttqapor4.fsf-monnier+emacs@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <jwvttqapor4.fsf-monnier+emacs@HIDDEN> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66750 Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Stefan. On Sat, Oct 28, 2023 at 15:13:16 -0400, Stefan Monnier wrote: > >> I like the idea of keeping better track of the origin of lambda > >> expressions (tho, admittedly, the same problem occurs with other kinds > >> of data: I have several times been faced with a keymap or a char-table, > >> wondering where the heel it came from). > > Maybe something similar might be possible for those type of objects. > [ Hmm... food for thought... ] > >> I took a look at > >> git log -p main..origin/feature/named-lambdas > >> but that's 127kB, so ... could [you] briefly describe the overall design > >> (IOW, how it's seen by ELisp programmers, byte-compiler hackers, and > >> ELisp users)? > > Certainly. Each lambda expression has (usually) a defun within which it > > is defined. Sometimes it's in a defvar, or defcustom. That > > @dfn{defining symbol} is recorded in the lambda form in one of three > > ways: > > (i) For a cons form, it's (cadr form), a new field inserted between the > > symbol `lambda' and the argument list. > > (ii) For a byte-compiled form, it's (aref form 5), this new field going > > after the doc string and before any interactive form in the compiled > > form. > These two change the visible representation of functions, so I wouldn't > be surprised if they break some odd hack out there. There were a few in the test suite I had to amend. > For (i), do we actually care enough to keep that info (IME the > functions are usually compiled, and if they're not the code itself > usually makes it fairly easy to find the code's origin)? I considered that for some time, and in the end thought that on grounds of consistency it would be better to put the defining symbol into the list form as well. > For (ii), why did you choose slot 5, thus moving the interactive-form > slot? Because an interactive form of nil means "(interactive)" with no arguments. Only an absent (aref form 6) means there isn't an interactive form. So it had to stay as the last slot. > > There are lots of detailed changes in eval.c and bytecomp.el (and > > friends). Also the macro `lambda' in subr.el has been amended to insert > > the current global defining-symbol if there isn't already a non-nil > > symbol in that position. > So the source code can manually provide this extra symbol in `lambda`? > Where have you found that useful? The first few functions in debug-early.el and byte-run.el, for a start. There, there is not yet a defmacro macro. Also in comp-trampoline-compile, where there doesn't seem to be any other way to get the name of the primitive into the defining symbol. I think there'll be quite a few other places, too. > >> Also, what other approaches have you considered/tried and what were the > >> problems you've encountered, if any? > > feature/named-lambdas was originally intended for use in backtraces. > > For the current bug, I've considered individually replacing each lambda > > with a named defun, so that C-h v will show that name rather than an > Hmm... as a user, rather than the enclosing definition I think I'd > expect to get some kind of source information like FILE+LINE+COL. Possibly: either is a good deal better than what we have at the moment. > If we give up on keeping that extra info in interpreted functions, the > FILE+LINE+COL information is readily available to the byte-compiler, > thanks to that famous Alan guy. :-) > Actually, the bytecode functions can already keep the FILE info (in > the form of the (FILE . OFFSET) cons cell in the docstring slot of the > bytecode object), we just opt never to expose that FILE info to the user > (we only use it to fetch the actual docstring). That's the offset in the .elc file, though, not the source. > [ Tho, admittedly, it's also that the byte-compiler only uses such > (FILE . OFFSET) for named functions, but it wouldn't be hard to change. ] > As for how/where to store the LINE+COL, I guess (aref form 5) is still > an option, although, maybe we should store that info alongside the > docstring, like we already do for the arglist. Well, the doc string is at (aref form 4). :-) > The way we do it for the arglist is hideous and a pain in the rear (I > blame the maintainers who accepted my patch back then), so it would be > an opportunity to "do it right" this time. > Stefan -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 19:14:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 15:14:00 2023 Received: from localhost ([127.0.0.1]:39576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwokx-0006WR-RY for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 15:14:00 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1qwoku-0006WD-ML for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 15:13:58 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D39F280283; Sat, 28 Oct 2023 15:13:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1698520397; bh=2mK4vcDN6CjNngTPb0Hk/Y6t94nZ/mdRUvvglKIF2G4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aMbOydptnmBhcSyM7b/bCrkiEKZsyZlBM9sItFb1rH7vTP409HE49wkUpBTPhCaMU 9MthaGJ9OVmRZKeKfhMVzsJhqzmU5MDyzHiLyHygCq6l0+BZ1wKyareUGxcPdeXbyI atu4NKvSFGfg1hPOzEPRmFY/7sQCwcTv8nx+vQx7YBovlJpWJRZIodbSE2SF6Aq7OP Ry8OMnnmNq+9/ff4Y/ndN051ohQEQV36JzUALZWzpocpxeVKJRKJ9pb1GuJMG9m7TE LxKjddRO5s0YSUnH55io4deONo3VsU6oXOrjVrgylrjKzBg3h1h6Gy+pn54j126BQc 8fTK7uaknc/gA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BB98B807D7; Sat, 28 Oct 2023 15:13:17 -0400 (EDT) Received: from pastel (unknown [45.72.195.71]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8C9ED120352; Sat, 28 Oct 2023 15:13:17 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Alan Mackenzie <acm@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value In-Reply-To: <ZT1QIC9T__WSn87L@ACM> (Alan Mackenzie's message of "Sat, 28 Oct 2023 18:17:04 +0000") Message-ID: <jwvttqapor4.fsf-monnier+emacs@HIDDEN> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> <jwv5y2qr7v8.fsf-monnier+emacs@HIDDEN> <ZT1QIC9T__WSn87L@ACM> Date: Sat, 28 Oct 2023 15:13:16 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.001 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66750 Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> I like the idea of keeping better track of the origin of lambda >> expressions (tho, admittedly, the same problem occurs with other kinds >> of data: I have several times been faced with a keymap or a char-table, >> wondering where the heel it came from). > Maybe something similar might be possible for those type of objects. [ Hmm... food for thought... ] >> I took a look at > >> git log -p main..origin/feature/named-lambdas > >> but that's 127kB, so ... could [you] briefly describe the overall design >> (IOW, how it's seen by ELisp programmers, byte-compiler hackers, and >> ELisp users)? > > Certainly. Each lambda expression has (usually) a defun within which it > is defined. Sometimes it's in a defvar, or defcustom. That > @dfn{defining symbol} is recorded in the lambda form in one of three > ways: > (i) For a cons form, it's (cadr form), a new field inserted between the > symbol `lambda' and the argument list. > (ii) For a byte-compiled form, it's (aref form 5), this new field going > after the doc string and before any interactive form in the compiled > form. These two change the visible representation of functions, so I wouldn't be surprised if they break some odd hack out there. For (i), do we actually care enough to keep that info (IME the functions are usually compiled, and if they're not the code itself usually makes it fairly easy to find the code's origin)? For (ii), why did you choose slot 5, thus moving the interactive-form slot? > There are lots of detailed changes in eval.c and bytecomp.el (and > friends). Also the macro `lambda' in subr.el has been amended to insert > the current global defining-symbol if there isn't already a non-nil > symbol in that position. So the source code can manually provide this extra symbol in `lambda`? Where have you found that useful? >> Also, what other approaches have you considered/tried and what were the >> problems you've encountered, if any? > feature/named-lambdas was originally intended for use in backtraces. > For the current bug, I've considered individually replacing each lambda > with a named defun, so that C-h v will show that name rather than an Hmm... as a user, rather than the enclosing definition I think I'd expect to get some kind of source information like FILE+LINE+COL. If we give up on keeping that extra info in interpreted functions, the FILE+LINE+COL information is readily available to the byte-compiler, thanks to that famous Alan guy. Actually, the bytecode functions can already keep the FILE info (in the form of the (FILE . OFFSET) cons cell in the docstring slot of the bytecode object), we just opt never to expose that FILE info to the user (we only use it to fetch the actual docstring). [ Tho, admittedly, it's also that the byte-compiler only uses such (FILE . OFFSET) for named functions, but it wouldn't be hard to change. ] As for how/where to store the LINE+COL, I guess (aref form 5) is still an option, although, maybe we should store that info alongside the docstring, like we already do for the arglist. The way we do it for the arglist is hideous and a pain in the rear (I blame the maintainers who accepted my patch back then), so it would be an opportunity to "do it right" this time. Stefan
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 18:59:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 14:59:56 2023 Received: from localhost ([127.0.0.1]:39569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwoXM-00069R-9J for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 14:59:56 -0400 Received: from mail.muc.de ([193.149.48.3]:60225) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1qwoXJ-00069C-0z for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 14:59:54 -0400 Received: (qmail 48419 invoked by uid 3782); 28 Oct 2023 20:59:15 +0200 Received: from acm.muc.de (p4fe15319.dip0.t-ipconnect.de [79.225.83.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 28 Oct 2023 20:59:14 +0200 Received: (qmail 20491 invoked by uid 1000); 28 Oct 2023 18:59:14 -0000 Date: Sat, 28 Oct 2023 18:59:14 +0000 To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Message-ID: <ZT1aAg7G0Ob5bAE8@ACM> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> <jwv5y2qr7v8.fsf-monnier+emacs@HIDDEN> <ZT1QIC9T__WSn87L@ACM> <838r7md237.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <838r7md237.fsf@HIDDEN> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66750 Cc: acorallo@HIDDEN, 66750 <at> debbugs.gnu.org, monnier@HIDDEN, acm@HIDDEN, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Eli. On Sat, Oct 28, 2023 at 21:38:36 +0300, Eli Zaretskii wrote: > > Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, > > Stefan Kangas <stefankangas@HIDDEN>, acm@HIDDEN > > Date: Sat, 28 Oct 2023 18:17:04 +0000 > > From: Alan Mackenzie <acm@HIDDEN> > > > but that's 127kB, so ... could [you] briefly describe the overall design > > > (IOW, how it's seen by ELisp programmers, byte-compiler hackers, and > > > ELisp users)? > > Certainly. Each lambda expression has (usually) a defun within which it > > is defined. Sometimes it's in a defvar, or defcustom. That > > @dfn{defining symbol} is recorded in the lambda form in one of three > > ways: > > (i) For a cons form, it's (cadr form), a new field inserted between the > > symbol `lambda' and the argument list. > > (ii) For a byte-compiled form, it's (aref form 5), this new field going > > after the doc string and before any interactive form in the compiled > > form. > > (iii) For a native-compiled subr it's (subr-native-defining-symbol > > subr), a function defined in data.c. It accesses a new field in struct > > Lisp_Subr called defining_symbol. > > There are lots of detailed changes in eval.c and bytecomp.el (and > > friends). Also the macro `lambda' in subr.el has been amended to insert > > the current global defining-symbol if there isn't already a non-nil > > symbol in that position. cl-print-object/compiled-function has been > > amended to print the defining-symbol, and there is a new > > cl-print-object/subr which does the same. > > The intention is that compiled objects from earlier Emacsen can still be > > loaded and run by feature/named-lambdas, just without the defining > > symbols (which will appear to be nil). > > > Also, what other approaches have you considered/tried and what were the > > > problems you've encountered, if any? > > feature/named-lambdas was originally intended for use in backtraces. > > For the current bug, I've considered individually replacing each lambda > > with a named defun, so that C-h v will show that name rather than an > > unhelpful byte/native compiled anonymous function. That would be a lot > > of work - my scripting found 63 defcustoms set to lambdas, 29 uses in > > doc strings, and 215 suspicious occurrences with ordinary variables > > (quite a few of which will be harmless). Amending all these (I guess > > around 200 lambdas) would probably be too much work. > Thanks. However, now I'm confused: what exactly does this feature > give us, if it doesn't handle all the lambdas in the Emacs tree and > (AFAIU) will not affect lambdas in third-party packages? Which > lambdas will now have a defining symbol, and which will not? It will handle all the lambdas in the Emacs tree. Each of them will get a defining-symbol set. Also third-party packages with lambdas will also get defining-symbols, provided they are compiled with feature/named-lambdas. It's just that .elc's/.eln's built with, say, Emacs-29 will continue to be loadable and runnable, but obviously without the defining symbol facility for those lambdas. -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 18:39:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 14:39:29 2023 Received: from localhost ([127.0.0.1]:39548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwoDY-0005Xy-Md for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 14:39:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55292) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qwoDX-0005Xl-Jx for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 14:39:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qwoCv-0001p9-Ln; Sat, 28 Oct 2023 14:38:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1JRNHzxtWwmnW9+Dd9R+5wdMDSdcLn0+EgwEVhHAkVY=; b=IYoS7ISFsY+8 3xQIdURX/goNRjWUB3QyZjSd8KtFnbEzDKdJBSVi0qqmXKDwjhmlm4CwInHPB2cOEVOUttRfT3hYg eJhGY/5pBC3DTWunNbDn4OawOyNBeK/zXrS42RKcqMMts0VpRbVBip9qJ+eZGYh7BZRZOQ3XE/UPF wLXEvFmTeA7gCya6j5W4/0Hoj8Dp560cqfyqT5uCms6nLri6QbZvN59A+RI2a+ok+xuU/YbBERJ0g zemOpzimFzLuTZa4i1gWCuLqGgaHLFuXS4M52nFg3YtXdtUANsvFD4gZElmo9og7X2Zxd1OBOcTkC Ics+GsLmQTE2Ay8sjmNpCQ==; Date: Sat, 28 Oct 2023 21:38:36 +0300 Message-Id: <838r7md237.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Alan Mackenzie <acm@HIDDEN> In-Reply-To: <ZT1QIC9T__WSn87L@ACM> (message from Alan Mackenzie on Sat, 28 Oct 2023 18:17:04 +0000) Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> <jwv5y2qr7v8.fsf-monnier+emacs@HIDDEN> <ZT1QIC9T__WSn87L@ACM> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66750 Cc: acorallo@HIDDEN, 66750 <at> debbugs.gnu.org, monnier@HIDDEN, stefankangas@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, > Stefan Kangas <stefankangas@HIDDEN>, acm@HIDDEN > Date: Sat, 28 Oct 2023 18:17:04 +0000 > From: Alan Mackenzie <acm@HIDDEN> > > > but that's 127kB, so ... could [you] briefly describe the overall design > > (IOW, how it's seen by ELisp programmers, byte-compiler hackers, and > > ELisp users)? > > Certainly. Each lambda expression has (usually) a defun within which it > is defined. Sometimes it's in a defvar, or defcustom. That > @dfn{defining symbol} is recorded in the lambda form in one of three > ways: > (i) For a cons form, it's (cadr form), a new field inserted between the > symbol `lambda' and the argument list. > (ii) For a byte-compiled form, it's (aref form 5), this new field going > after the doc string and before any interactive form in the compiled > form. > (iii) For a native-compiled subr it's (subr-native-defining-symbol > subr), a function defined in data.c. It accesses a new field in struct > Lisp_Subr called defining_symbol. > > There are lots of detailed changes in eval.c and bytecomp.el (and > friends). Also the macro `lambda' in subr.el has been amended to insert > the current global defining-symbol if there isn't already a non-nil > symbol in that position. cl-print-object/compiled-function has been > amended to print the defining-symbol, and there is a new > cl-print-object/subr which does the same. > > The intention is that compiled objects from earlier Emacsen can still be > loaded and run by feature/named-lambdas, just without the defining > symbols (which will appear to be nil). > > > Also, what other approaches have you considered/tried and what were the > > problems you've encountered, if any? > > feature/named-lambdas was originally intended for use in backtraces. > > For the current bug, I've considered individually replacing each lambda > with a named defun, so that C-h v will show that name rather than an > unhelpful byte/native compiled anonymous function. That would be a lot > of work - my scripting found 63 defcustoms set to lambdas, 29 uses in > doc strings, and 215 suspicious occurrences with ordinary variables > (quite a few of which will be harmless). Amending all these (I guess > around 200 lambdas) would probably be too much work. Thanks. However, now I'm confused: what exactly does this feature give us, if it doesn't handle all the lambdas in the Emacs tree and (AFAIU) will not affect lambdas in third-party packages? Which lambdas will now have a defining symbol, and which will not?
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 18:17:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 14:17:47 2023 Received: from localhost ([127.0.0.1]:39523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwnsZ-0004wn-4C for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 14:17:47 -0400 Received: from mail.muc.de ([193.149.48.3]:58995) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1qwnsV-0004wU-As for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 14:17:45 -0400 Received: (qmail 1658 invoked by uid 3782); 28 Oct 2023 20:17:05 +0200 Received: from acm.muc.de (p4fe15319.dip0.t-ipconnect.de [79.225.83.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 28 Oct 2023 20:17:04 +0200 Received: (qmail 20248 invoked by uid 1000); 28 Oct 2023 18:17:04 -0000 Date: Sat, 28 Oct 2023 18:17:04 +0000 To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Message-ID: <ZT1QIC9T__WSn87L@ACM> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> <jwv5y2qr7v8.fsf-monnier+emacs@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <jwv5y2qr7v8.fsf-monnier+emacs@HIDDEN> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66750 Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Stefan. On Sat, Oct 28, 2023 at 13:17:13 -0400, Stefan Monnier wrote: > >> > Currently feature/named-lambdas is mostly working, not fully working. > Didn't know about this feature. It's been hanging around the savannah repository since July. > I like the idea of keeping better track of the origin of lambda > expressions (tho, admittedly, the same problem occurs with other kinds > of data: I have several times been faced with a keymap or a char-table, > wondering where the heel it came from). Maybe something similar might be possible for those type of objects. > I took a look at > git log -p main..origin/feature/named-lambdas > but that's 127kB, so ... could [you] briefly describe the overall design > (IOW, how it's seen by ELisp programmers, byte-compiler hackers, and > ELisp users)? Certainly. Each lambda expression has (usually) a defun within which it is defined. Sometimes it's in a defvar, or defcustom. That @dfn{defining symbol} is recorded in the lambda form in one of three ways: (i) For a cons form, it's (cadr form), a new field inserted between the symbol `lambda' and the argument list. (ii) For a byte-compiled form, it's (aref form 5), this new field going after the doc string and before any interactive form in the compiled form. (iii) For a native-compiled subr it's (subr-native-defining-symbol subr), a function defined in data.c. It accesses a new field in struct Lisp_Subr called defining_symbol. There are lots of detailed changes in eval.c and bytecomp.el (and friends). Also the macro `lambda' in subr.el has been amended to insert the current global defining-symbol if there isn't already a non-nil symbol in that position. cl-print-object/compiled-function has been amended to print the defining-symbol, and there is a new cl-print-object/subr which does the same. The intention is that compiled objects from earlier Emacsen can still be loaded and run by feature/named-lambdas, just without the defining symbols (which will appear to be nil). > Also, what other approaches have you considered/tried and what were the > problems you've encountered, if any? feature/named-lambdas was originally intended for use in backtraces. For the current bug, I've considered individually replacing each lambda with a named defun, so that C-h v will show that name rather than an unhelpful byte/native compiled anonymous function. That would be a lot of work - my scripting found 63 defcustoms set to lambdas, 29 uses in doc strings, and 215 suspicious occurrences with ordinary variables (quite a few of which will be harmless). Amending all these (I guess around 200 lambdas) would probably be too much work. > Stefan -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 17:17:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 13:17:57 2023 Received: from localhost ([127.0.0.1]:39485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwmwe-0003QK-QW for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 13:17:57 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1qwmwb-0003Q4-Vn for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 13:17:54 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3FF294407F6; Sat, 28 Oct 2023 13:17:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1698513435; bh=cI+YDwFwh0Q7WjKucicEi8PRgCfgV9G0ACwOdPoDKzA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=B5RRgM6AqFh5UnusZ00niO20659FX1LLAvSNoPDTyb+cnfi1xwy8q6HvyU3Z5bkfT iO0FH/G1BKK6p5EsJM+ot4JG+mprQoK33rg9Y/bkP0wzMO8dU+5L9qh9EwZWQrT6By +z5pfYyCO3DoVQH6KIiRy6s9Vt1hLHt8MLIMJgfDsGai0X1UaRTbvT1QIUw/IJu8tz lAGLhH1mG9Seq1Uolvc4vKqxI92GV9TLfKHUwkWwS+QYVuSK6luORKBjD8wB2Xmeal nuVgcgnb+//vPegoMNTdHg3wBirxAjrzTL6/Rw/HhT9fEQr7jcMgUWqRI4vXUIaOp/ kSBhm9jpXex7A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4AEDC44068F; Sat, 28 Oct 2023 13:17:15 -0400 (EDT) Received: from pastel (unknown [45.72.195.71]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 11878120079; Sat, 28 Oct 2023 13:17:15 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Alan Mackenzie <acm@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value In-Reply-To: <ZT0v3vjscJMM7K87@ACM> (Alan Mackenzie's message of "Sat, 28 Oct 2023 15:59:26 +0000") Message-ID: <jwv5y2qr7v8.fsf-monnier+emacs@HIDDEN> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> Date: Sat, 28 Oct 2023 13:17:13 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.003 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66750 Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) >> > Currently feature/named-lambdas is mostly working, not fully working. Didn't know about this feature. I like the idea of keeping better track of the origin of lambda expressions (tho, admittedly, the same problem occurs with other kinds of data: I have several times been faced with a keymap or a char-table, wondering where the heel it came from). I took a look at git log -p main..origin/feature/named-lambdas but that's 127kB, so ... could briefly describe the overall design (IOW, how it's seen by ELisp programmers, byte-compiler hackers, and ELisp users)? Also, what other approaches have you considered/tried and what were the problems you've encountered, if any? Stefan
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 16:58:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 12:58:22 2023 Received: from localhost ([127.0.0.1]:39466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwmdh-0000Lx-RB for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 12:58:22 -0400 Received: from mail.muc.de ([193.149.48.3]:56472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1qwmdf-0000Lj-Rb for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 12:58:20 -0400 Received: (qmail 11622 invoked by uid 3782); 28 Oct 2023 18:57:41 +0200 Received: from acm.muc.de (p4fe15319.dip0.t-ipconnect.de [79.225.83.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 28 Oct 2023 18:57:41 +0200 Received: (qmail 19812 invoked by uid 1000); 28 Oct 2023 16:57:40 -0000 Date: Sat, 28 Oct 2023 16:57:40 +0000 To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Message-ID: <ZT09hKlIg7esLDRs@ACM> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> <83bkcid87i.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83bkcid87i.fsf@HIDDEN> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66750 Cc: acorallo@HIDDEN, 66750 <at> debbugs.gnu.org, stefankangas@HIDDEN, acm@HIDDEN, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Eli. On Sat, Oct 28, 2023 at 19:26:25 +0300, Eli Zaretskii wrote: > > Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, > > Stefan Monnier <monnier@HIDDEN>, acm@HIDDEN > > Date: Sat, 28 Oct 2023 15:59:26 +0000 > > From: Alan Mackenzie <acm@HIDDEN> > > Hello, Stefan. > > On Sat, Oct 28, 2023 at 08:04:00 -0700, Stefan Kangas wrote: > > > Alan Mackenzie <acm@HIDDEN> writes: > > > > Currently feature/named-lambdas is mostly working, not fully working. > > > > Probably the most pressing of these deficiencies is that native compiled > > > > lambda functions don't yet get their defining symbol set. > > As I've said, this is now fixed. > Above, you are talking about "the most pressing of these > deficiencies", which is now fixed. What other deficiencies or issues > are you aware of? I'm not aware of anywhere else where the code doesn't work. I'm not sure whether or not there are any other defining macros (things like define-minor-mode) which need amendment. I don't think any user documentation is needed. > Please provide a full list, so we could make an informed decision > whether the feature branch is ready to be landed. There are currently no ert tests for the new feature. -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 16:27:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 12:27:20 2023 Received: from localhost ([127.0.0.1]:39439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwm9g-0007yL-KL for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 12:27:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qwm9b-0007y5-7N for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 12:27:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qwm8z-0005ct-6Q; Sat, 28 Oct 2023 12:26:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=GzHnXY2n0hLLrCHLQXm6VWHCLtoN0KvPX6gKArj5+8c=; b=PCTJxTCOHlSm 6eaevTyAvcmueREcrGvy1xTxHAtIxk3pl98ISIDWjtg+75jj5lhZafcDXTHNa/QGHJCi6zqzUcVAQ sWw5w/k1y5g13ezq4cK1+hfpangNOQQ7eXsooy76wNVxsrFEW472nK3dL+c78bB7j/rYwtGp7iGji umQwDK5+VCIFQU8XLUvk0Vvb1VutDXzDHbvrYbDayJKvS/oQfZxQr+R3mkLYLTwHxkHDs03+Y5C9J lbXMt8PPbJsmEB5sAPTBowj8lVl1N0r0jJkXi2te9riAX/81+swiZmwWdc9OfAqKr7ntYxUD/8TL/ Z5Wu/XQJD6qfJDVdO2IRog==; Date: Sat, 28 Oct 2023 19:26:25 +0300 Message-Id: <83bkcid87i.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Alan Mackenzie <acm@HIDDEN> In-Reply-To: <ZT0v3vjscJMM7K87@ACM> (message from Alan Mackenzie on Sat, 28 Oct 2023 15:59:26 +0000) Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> <ZT0v3vjscJMM7K87@ACM> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66750 Cc: acorallo@HIDDEN, 66750 <at> debbugs.gnu.org, stefankangas@HIDDEN, acm@HIDDEN, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, > Stefan Monnier <monnier@HIDDEN>, acm@HIDDEN > Date: Sat, 28 Oct 2023 15:59:26 +0000 > From: Alan Mackenzie <acm@HIDDEN> > > Hello, Stefan. > > On Sat, Oct 28, 2023 at 08:04:00 -0700, Stefan Kangas wrote: > > Alan Mackenzie <acm@HIDDEN> writes: > > > > Currently feature/named-lambdas is mostly working, not fully working. > > > Probably the most pressing of these deficiencies is that native compiled > > > lambda functions don't yet get their defining symbol set. > > As I've said, this is now fixed. Above, you are talking about "the most pressing of these deficiencies", which is now fixed. What other deficiencies or issues are you aware of? Please provide a full list, so we could make an informed decision whether the feature branch is ready to be landed.
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 16:00:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 12:00:08 2023 Received: from localhost ([127.0.0.1]:39410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwljM-0007Jm-3W for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 12:00:08 -0400 Received: from mail.muc.de ([193.149.48.3]:54798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1qwljJ-0007Hb-9M for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 12:00:06 -0400 Received: (qmail 46475 invoked by uid 3782); 28 Oct 2023 17:59:27 +0200 Received: from acm.muc.de (p4fe15319.dip0.t-ipconnect.de [79.225.83.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 28 Oct 2023 17:59:26 +0200 Received: (qmail 19405 invoked by uid 1000); 28 Oct 2023 15:59:26 -0000 Date: Sat, 28 Oct 2023 15:59:26 +0000 To: Stefan Kangas <stefankangas@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Message-ID: <ZT0v3vjscJMM7K87@ACM> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66750 Cc: 66750 <at> debbugs.gnu.org, Andrea Corallo <acorallo@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, acm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Stefan. On Sat, Oct 28, 2023 at 08:04:00 -0700, Stefan Kangas wrote: > Alan Mackenzie <acm@HIDDEN> writes: > > Currently feature/named-lambdas is mostly working, not fully working. > > Probably the most pressing of these deficiencies is that native compiled > > lambda functions don't yet get their defining symbol set. As I've said, this is now fixed. > > There have been substantial amendments compared with the master branch, > > and it has not been tested much by anybody but me. > > Assuming it can be brought to a fully working state, there would be an > > extra symbol in each function definition which would make Emacs > > marginally bigger. > Does it have any performance implications? Yes, but very little. If I scroll through xdisp.c, displaying all the time, in C Mode: (i) master: 18.850s, 18.767s, 18.747s. (ii) feature/named-lambdas: 18.630s, 18.738s, 18.782s. If I likewise scroll through osprey_reg_map_macro.h (a 4 MB .h file specifying some hardware registers), in c-ts-mode: (i) master: 10.157s, 10.203s, 10.169s (ii) feature/named-lambdas: 10.207s, 10.219s, 10.257s .. Not a very scientific timing, not done from emacs -Q, but a fair test. It would seem any slowdown is less than 1%. -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 15:04:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 11:04:45 2023 Received: from localhost ([127.0.0.1]:39369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwkrl-0003EF-IC for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 11:04:45 -0400 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:55476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1qwkrf-0003Dw-U8 for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 11:04:44 -0400 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2c6b48cb2b6so4570041fa.2 for <66750 <at> debbugs.gnu.org>; Sat, 28 Oct 2023 08:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698505442; x=1699110242; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=VUo+VtetLR1JjNpQF1p0GkkfW8fCz/e9WT2gb7IttIo=; b=EVSEz06TJO0qSVNeiZB9+N4zdH04swljtMZd11ReFl7KKFeqq/n3zh6WoLeW8Wqdvi emJfYoaOXfOdxHIwx7LTL7/DXtFtLqFMt0O08XIh56TJs5yeGaqqku150EZL3y3NXkNg kVOh3pF4yxMsIc7imkx+SudLlEen+/6RVIR7fml18HcpAlHMo0IxwSFKUAZqcr410zQ/ SJz4pJf9ctJpKhruEhy4JzlUESFopbSUAFwhUVswH1IKnTBserUdmqwIey2R3+toA4JU NwyPwarmY6T+Tkpt5JrMkg0eNZrZ/tlHU0CtC7uOLiaBQKQOX0Kds8aV4zjlnQvdfRvj d3Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698505442; x=1699110242; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VUo+VtetLR1JjNpQF1p0GkkfW8fCz/e9WT2gb7IttIo=; b=ZSEOjpx7GhlVlAKj+45t7mTmA4UtktPyRaQ2nO3YW1i0nZq481x7x5fkMtIjqWGpLl OzHkDLLLcKg0GrT4ssmVsapHfsR1jLnBbeGQwiLDpIWYSdLJWeV+3XvJJnfTEdcnGhRU Yx0+SqVn6ghQIH4FhWm8JQBmLh10Bxi0IYzX39Ai9DHzlswovHxoxcQ53xknS6rD4cqE B1dFCxPG+HFtBT4SQii1J8G7sVZYUhIdP3bueQ25ZkhwFIAQjcX67/LLddm94JZTv0OD hRq4jtoTpyG0sbYvqP66LyWUFO6yEpAAHMAO0FtOt+SLZRbniekRx46Er5vZRHGBwUjs dQpw== X-Gm-Message-State: AOJu0YxdyXinbNmFB71v7dvfFzfPtN0fXU/bcImRFiIXTfvv7XKLON68 t7U4xRrQjsDEjM73vRvV2/LJQUo8czV9re/ndVY= X-Google-Smtp-Source: AGHT+IFfOR2VQfFoe/7ehALtGk/quJppMd6hqlVpLQcDTQ7t4ltj83J2vIPRRTGlJY3ma3LDRirAtiZnrKDDFIaHuKE= X-Received: by 2002:a2e:99c6:0:b0:2c5:72e:6ff7 with SMTP id l6-20020a2e99c6000000b002c5072e6ff7mr4280980ljj.24.1698505441475; Sat, 28 Oct 2023 08:04:01 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 28 Oct 2023 08:04:00 -0700 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <ZTugdCOArtXvEaR8@ACM> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> MIME-Version: 1.0 Date: Sat, 28 Oct 2023 08:04:00 -0700 Message-ID: <CADwFkmkb8hyFLF59f9nWhVXKtR9VE2O-YPg8eA_AoK+j6_vHNw@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value To: Alan Mackenzie <acm@HIDDEN>, Andrea Corallo <acorallo@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 66750 Cc: 66750 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Alan Mackenzie <acm@HIDDEN> writes: > Currently feature/named-lambdas is mostly working, not fully working. > Probably the most pressing of these deficiencies is that native compiled > lambda functions don't yet get their defining symbol set. > > There have been substantial amendments compared with the master branch, > and it has not been tested much by anybody but me. > > Assuming it can be brought to a fully working state, there would be an > extra symbol in each function definition which would make Emacs > marginally bigger. Does it have any performance implications?
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 28 Oct 2023 09:27:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 28 05:27:59 2023 Received: from localhost ([127.0.0.1]:37756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwfbq-0002Ih-QX for submit <at> debbugs.gnu.org; Sat, 28 Oct 2023 05:27:59 -0400 Received: from mail.muc.de ([193.149.48.3]:43603) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1qwfbm-0002IO-St for 66750 <at> debbugs.gnu.org; Sat, 28 Oct 2023 05:27:57 -0400 Received: (qmail 8478 invoked by uid 3782); 28 Oct 2023 11:27:16 +0200 Received: from acm.muc.de (p4fe15319.dip0.t-ipconnect.de [79.225.83.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 28 Oct 2023 11:27:15 +0200 Received: (qmail 26386 invoked by uid 1000); 28 Oct 2023 09:27:15 -0000 Date: Sat, 28 Oct 2023 09:27:15 +0000 To: Andrea Corallo <acorallo@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Message-ID: <ZTzT85HGsSAlBLNb@ACM> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> <ZTugdCOArtXvEaR8@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <ZTugdCOArtXvEaR8@ACM> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66750 Cc: acm@HIDDEN, 66750 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Andrea. On Fri, Oct 27, 2023 at 11:35:16 +0000, Alan Mackenzie wrote: > On Wed, Oct 25, 2023 at 16:53:38 -0400, Andrea Corallo wrote: > > Alan Mackenzie <acm@HIDDEN> writes: [ .... ] > > > I see two ways to fix this bug: > > > (i) Systematically to replace each of these lambda functions by a named > > > defun. > > > (ii) To adopt git branch feature/named-lambdas, which attaches to every > > > lambda function the name of the defun (or defvar) in which it was > > > defined. This extra information could then be printed out for C-h v, > > > something like this: > > > Its value is > > > {isearch-fold-quotes-mode} #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109> > > > Original value was nil > > > Local in buffer *info*<3>; global value is nil > > > , thus enabling the user quickly to locate the source of the lambda form > > > in isearch.el. > > Hi Alan, > > what (if any) do you think are the downsides of option ii? > Currently feature/named-lambdas is mostly working, not fully working. > Probably the most pressing of these deficiencies is that native compiled > lambda functions don't yet get their defining symbol set. They do now. In feature/named-lambdas, I now see C-h v search-default-mode giving the above display when invoked from an info buffer. > There have been substantial amendments compared with the master branch, > and it has not been tested much by anybody but me. > Assuming it can be brought to a fully working state, there would be an > extra symbol in each function definition which would make Emacs > marginally bigger. > > Thanks > > Andrea -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 27 Oct 2023 11:36:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 27 07:36:01 2023 Received: from localhost ([127.0.0.1]:35265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qwL8D-0001A1-2T for submit <at> debbugs.gnu.org; Fri, 27 Oct 2023 07:36:01 -0400 Received: from mail.muc.de ([193.149.48.3]:61063) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1qwL89-00019m-JW for 66750 <at> debbugs.gnu.org; Fri, 27 Oct 2023 07:35:59 -0400 Received: (qmail 92678 invoked by uid 3782); 27 Oct 2023 13:35:20 +0200 Received: from acm.muc.de (p4fe15c53.dip0.t-ipconnect.de [79.225.92.83]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 27 Oct 2023 13:35:20 +0200 Received: (qmail 8001 invoked by uid 1000); 27 Oct 2023 11:35:16 -0000 Date: Fri, 27 Oct 2023 11:35:16 +0000 To: Andrea Corallo <acorallo@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Message-ID: <ZTugdCOArtXvEaR8@ACM> References: <ZTlL4VGOzZ07cpz5@ACM> <yp1wmvah19p.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <yp1wmvah19p.fsf@HIDDEN> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 66750 Cc: acm@HIDDEN, 66750 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Hello, Andrea. On Wed, Oct 25, 2023 at 16:53:38 -0400, Andrea Corallo wrote: > Alan Mackenzie <acm@HIDDEN> writes: > > Hello, Emacs. > > Supposing a variable has as a value a lambda function. On doing C-h v > > for this variable, there ensues a useless lack of information about the > > lambda. All one gets told is that it is a lambda function, not where the > > source code for it is, or anything useful like that. [ .... ] > > ######################################################################### > > I see two ways to fix this bug: > > (i) Systematically to replace each of these lambda functions by a named > > defun. > > (ii) To adopt git branch feature/named-lambdas, which attaches to every > > lambda function the name of the defun (or defvar) in which it was > > defined. This extra information could then be printed out for C-h v, > > something like this: > > Its value is > > {isearch-fold-quotes-mode} #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109> > > Original value was nil > > Local in buffer *info*<3>; global value is nil > > , thus enabling the user quickly to locate the source of the lambda form > > in isearch.el. > Hi Alan, > what (if any) do you think are the downsides of option ii? Currently feature/named-lambdas is mostly working, not fully working. Probably the most pressing of these deficiencies is that native compiled lambda functions don't yet get their defining symbol set. There have been substantial amendments compared with the master branch, and it has not been tested much by anybody but me. Assuming it can be brought to a fully working state, there would be an extra symbol in each function definition which would make Emacs marginally bigger. > Thanks > Andrea -- Alan Mackenzie (Nuremberg, Germany).
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at 66750) by debbugs.gnu.org; 25 Oct 2023 20:54:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 25 16:54:19 2023 Received: from localhost ([127.0.0.1]:60087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qvktO-0003S9-Dk for submit <at> debbugs.gnu.org; Wed, 25 Oct 2023 16:54:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acorallo@HIDDEN>) id 1qvktM-0003Ru-5C for 66750 <at> debbugs.gnu.org; Wed, 25 Oct 2023 16:54:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>) id 1qvksl-0005WJ-P9; Wed, 25 Oct 2023 16:53:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=g1oXGmOeDLw2WNN0xG5oOjsVX5IC5DZoXY2aqhh1Gdg=; b=aod1yFGwcsVFBTTJzF9l ASpoHNn7pnNOkDMppEl/INwEjUdAY6GfkBGahoerabbRshqVH3yMybegoIRE0OCcb1BPvVZL+ypaF Q/PGdX/rfcizHpdkbpKLUEL9o7hQyfc68lC/rgnsdh5ionhBldKsowAZzyQbPv1bnU5epgvpDiD1I k/n3khYlu0l4+rtT8SHJcfUEyuu9nFco4DCXTePJ9aLSdu2KAEAdY0PqCI8T5sitFZToLddUeqpZ8 mWjjUF54AIdlAeE+b5V76CftpYs0tTj6k/nO0lLrzpvn6VvpQ2jWKcpLG61oYoChMcC6zgiIBEyAg y6yUziw6NqriiQ==; Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from <acorallo@HIDDEN>) id 1qvksk-0006yB-V4; Wed, 25 Oct 2023 16:53:39 -0400 From: Andrea Corallo <acorallo@HIDDEN> To: Alan Mackenzie <acm@HIDDEN> Subject: Re: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value In-Reply-To: <ZTlL4VGOzZ07cpz5@ACM> (Alan Mackenzie's message of "Wed, 25 Oct 2023 17:09:53 +0000") References: <ZTlL4VGOzZ07cpz5@ACM> Date: Wed, 25 Oct 2023 16:53:38 -0400 Message-ID: <yp1wmvah19p.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 66750 Cc: 66750 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Alan Mackenzie <acm@HIDDEN> writes: > Hello, Emacs. > > Supposing a variable has as a value a lambda function. On doing C-h v > for this variable, there ensues a useless lack of information about the > lambda. All one gets told is that it is a lambda function, not where the > source code for it is, or anything useful like that. > > A typical example is C-h v search-default-mode, which prints something > like the following: > > Its value is > #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109> > Original value was nil > Local in buffer *info*<3>; global value is nil > > .. When native compilation is not enabled, the printout is only slightly > better. > > Merely amongst the customisable options (i.e. not ordinary defvars and > defconsts) there are approximately 63 places where these options get set > to lambda functions. The following list lists the file and line number > where it's done, and the customisable option it gets done to: > > ../autorevert.el:471 before-save-hook > ../emacs-lisp/pp.el:320 temp-buffer-show-function > ../emulation/viper.el:950 eshell-mode-hook > ../erc/erc-pcomplete.el:99 pcomplete-default-completion-function > ../eshell/em-cmpl.el:191 eshell-command-completion-function > ../eshell/em-cmpl.el:202 eshell-default-completion-function > ../eshell/em-cmpl.el:280 eshell-mode-hook > ../eshell/em-prompt.el:50 eshell-prompt-function > ../eshell/em-smart.el:187 eshell-post-command-hook > ../gnus/gnus-art.el:3077 gnus-exit-gnus-hook > ../gnus/gnus-delay.el:150 message-send-hook > ../gnus/gnus-diary.el:213 gnus-summary-menu-hook > ../gnus/gnus-diary.el:370 nndiary-request-accept-article-functions > ../gnus/gnus-draft.el:274 message-post-method > ../gnus/gnus-msg.el:1145 message-reply-to-function > ../gnus/gnus-msg.el:387 message-header-setup-hook > ../gnus/gnus-msg.el:392 message-mode-hook > ../gnus/gnus-registry.el:1000 gnus-summary-menu-hook > ../gnus/gnus-sum.el:1321 gnus-alter-articles-to-read-function > ../gnus/gnus-util.el:1205 iswitchb-make-buflist-hook > ../gnus/message.el:3157 facemenu-add-face-function > ../gnus/message.el:701 message-cite-level-function > ../gnus/nnmairix.el:286 nnmairix-widget-select-window-function > ../help.el:1946 temp-buffer-max-height > ../help.el:1963 temp-buffer-max-width > ../isearch.el:4685 search-default-mode > ../locate.el:670 locate-make-command-line > ../mail/emacsbug.el:466 message-sent-hook > ../mail/emacsbug.el:540 message-send-hook > ../mail/feedmail.el:1400 feedmail-queue-runner-mode-setter > ../mail/feedmail.el:1436 feedmail-queue-runner-message-sender > ../mail/feedmail.el:1457 feedmail-queue-runner-cleaner-upper > ../net/mairix.el:176 mairix-widget-select-window-function > ../obsolete/gulp.el:103 mail-setup-hook > ../org/ob-core.el:1524 org-mode-hook > ../org/ob-latex.el:101 org-babel-latex-end-env > ../org/ob-latex.el:79 org-babel-latex-preamble > ../org/ob-latex.el:90 org-babel-latex-begin-env > ../org/ob-python.el:208 python-shell-first-prompt-hook > ../org/ol-bibtex.el:268 org-bibtex-headline-format-function > ../org/org-compat.el:1272 imenu-after-jump-hook > ../org/org-compat.el:1276 org-mode-hook > ../org/org-compat.el:1339 speedbar-visiting-tag-hook > ../org/org-crypt.el:317 org-mode-hook > ../org/org-ctags.el:196 org-mode-hook > ../org/org.el:15220 after-save-hook > ../org/org.el:18651 occur-mode-find-occurrence-hook > ../org/org-mouse.el:866 org-mode-hook > ../org/ox-ascii.el:378 org-ascii-format-drawer-function > ../org/ox-html.el:657 org-html-format-drawer-function > ../org/ox-latex.el:888 org-latex-format-drawer-function > ../org/ox-odt.el:635 org-odt-format-drawer-function > ../org/ox-texinfo.el:334 org-texinfo-format-drawer-function > ../pcomplete.el:305 pcomplete-command-completion-function > ../pcomplete.el:315 pcomplete-default-completion-function > ../play/gametree.el:118 gametree-make-heading-function > ../progmodes/cperl-mode.el:1848 add-log-current-defun-function > ../progmodes/octave.el:607 fill-nobreak-predicate > ../progmodes/ps-mode.el:108 ps-mode-print-function > ../vc/add-log.el:1129 fill-nobreak-predicate > ../vc/emerge.el:2086 temp-buffer-show-function > ../vc/smerge-mode.el:1358 ediff-quit-hook > ../window.el:6662 pop-up-frame-function > > .. Additionally there are about 29 instances in the doc strings where > users are urged to use lambda functions (rather than defuns) for this > purpose. They are at: > > ../calendar/calendar.el:395 calendar-move-hook > ../calendar/cal-tex.el:154 cal-tex-hook > ../comint.el:189 comint-mode-hook > ../dired-loaddefs.el:646 dired-mode-hook > ../dired-x.el:152 dired-mode-hook > ../erc/erc-log.el:218 erc-enable-logging > ../erc/erc-page.el:55 erc-page-function > ../files.el:466 auto-save-visited-predicate > ../font-lock.el:704 c-mode-hook > ../gnus/gnus-sum.el:1044 gnus-select-group-hook > ../gnus/nnmail.el:179 nnmail-expiry-wait-function > ../gnus/nnmail.el:286 nnmail-read-incoming-hook > ../gnus/nnmail.el:299 nnmail-read-incoming-hook > ../icomplete.el:154 icomplete-minibuffer-setup-hook > ../ido.el:890 ido-minibuffer-setup-hook > ../ielm.el:63 ielm-mode-hook > ../ldefs-boot.el:29820 sql-mode-hook > ../ldefs-boot.el:5069 c-mode-hook > ../loaddefs.el:29950 sql-mode-hook > ../loaddefs.el:5069 c-mode-hook > ../obsolete/nnir.el:415 nnir-notmuch-filter-group-names-function > ../org/org-keys.el:688 org-use-speed-commands > ../org/ox-html.el:968 org-html-table-row-open-tag > ../progmodes/compile.el:885 c-mode-hook > ../progmodes/prog-mode.el:296 emacs-lisp-mode-hook > ../progmodes/sql.el:4134 sql-mode-hook > ../progmodes/sql.el:4256 sql-interactive-mode-hook > ../textmodes/tildify.el:156 tildify-foreach-region-function > ../transient.el:278 transient-substitute-key-function > > .. Furthermore there are, perhaps, around 150 such settings of ordinary > defvars or defconsts to lambda functions. > > ######################################################################### > > I see two ways to fix this bug: > (i) Systematically to replace each of these lambda functions by a named > defun. > (ii) To adopt git branch feature/named-lambdas, which attaches to every > lambda function the name of the defun (or defvar) in which it was > defined. This extra information could then be printed out for C-h v, > something like this: > > Its value is > {isearch-fold-quotes-mode} #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109> > Original value was nil > Local in buffer *info*<3>; global value is nil > > , thus enabling the user quickly to locate the source of the lambda form > in isearch.el. Hi Alan, what (if any) do you think are the downsides of option ii? Thanks Andrea
bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.Received: (at submit) by debbugs.gnu.org; 25 Oct 2023 17:11:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 25 13:11:00 2023 Received: from localhost ([127.0.0.1]:59930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qvhPI-0005bn-6O for submit <at> debbugs.gnu.org; Wed, 25 Oct 2023 13:11:00 -0400 Received: from lists.gnu.org ([2001:470:142::17]:52740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <acm@HIDDEN>) id 1qvhPD-0005bW-EU for submit <at> debbugs.gnu.org; Wed, 25 Oct 2023 13:10:59 -0400 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 <acm@HIDDEN>) id 1qvhOc-0006vl-VC for bug-gnu-emacs@HIDDEN; Wed, 25 Oct 2023 13:10:19 -0400 Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <acm@HIDDEN>) id 1qvhOW-00009i-Mo for bug-gnu-emacs@HIDDEN; Wed, 25 Oct 2023 13:10:18 -0400 Received: (qmail 93521 invoked by uid 3782); 25 Oct 2023 19:09:57 +0200 Received: from acm.muc.de (p4fe15c94.dip0.t-ipconnect.de [79.225.92.148]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 25 Oct 2023 19:09:57 +0200 Received: (qmail 29068 invoked by uid 1000); 25 Oct 2023 17:09:53 -0000 Date: Wed, 25 Oct 2023 17:09:53 +0000 To: bug-gnu-emacs@HIDDEN Subject: Unhelpful text in C-h v for variables with a lambda form as value Message-ID: <ZTlL4VGOzZ07cpz5@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie <acm@HIDDEN> X-Primary-Address: acm@HIDDEN Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@HIDDEN; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, T_SPF_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) Hello, Emacs. Supposing a variable has as a value a lambda function. On doing C-h v for this variable, there ensues a useless lack of information about the lambda. All one gets told is that it is a lambda function, not where the source code for it is, or anything useful like that. A typical example is C-h v search-default-mode, which prints something like the following: Its value is #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109> Original value was nil Local in buffer *info*<3>; global value is nil .. When native compilation is not enabled, the printout is only slightly better. Merely amongst the customisable options (i.e. not ordinary defvars and defconsts) there are approximately 63 places where these options get set to lambda functions. The following list lists the file and line number where it's done, and the customisable option it gets done to: ../autorevert.el:471 before-save-hook ../emacs-lisp/pp.el:320 temp-buffer-show-function ../emulation/viper.el:950 eshell-mode-hook ../erc/erc-pcomplete.el:99 pcomplete-default-completion-function ../eshell/em-cmpl.el:191 eshell-command-completion-function ../eshell/em-cmpl.el:202 eshell-default-completion-function ../eshell/em-cmpl.el:280 eshell-mode-hook ../eshell/em-prompt.el:50 eshell-prompt-function ../eshell/em-smart.el:187 eshell-post-command-hook ../gnus/gnus-art.el:3077 gnus-exit-gnus-hook ../gnus/gnus-delay.el:150 message-send-hook ../gnus/gnus-diary.el:213 gnus-summary-menu-hook ../gnus/gnus-diary.el:370 nndiary-request-accept-article-functions ../gnus/gnus-draft.el:274 message-post-method ../gnus/gnus-msg.el:1145 message-reply-to-function ../gnus/gnus-msg.el:387 message-header-setup-hook ../gnus/gnus-msg.el:392 message-mode-hook ../gnus/gnus-registry.el:1000 gnus-summary-menu-hook ../gnus/gnus-sum.el:1321 gnus-alter-articles-to-read-function ../gnus/gnus-util.el:1205 iswitchb-make-buflist-hook ../gnus/message.el:3157 facemenu-add-face-function ../gnus/message.el:701 message-cite-level-function ../gnus/nnmairix.el:286 nnmairix-widget-select-window-function ../help.el:1946 temp-buffer-max-height ../help.el:1963 temp-buffer-max-width ../isearch.el:4685 search-default-mode ../locate.el:670 locate-make-command-line ../mail/emacsbug.el:466 message-sent-hook ../mail/emacsbug.el:540 message-send-hook ../mail/feedmail.el:1400 feedmail-queue-runner-mode-setter ../mail/feedmail.el:1436 feedmail-queue-runner-message-sender ../mail/feedmail.el:1457 feedmail-queue-runner-cleaner-upper ../net/mairix.el:176 mairix-widget-select-window-function ../obsolete/gulp.el:103 mail-setup-hook ../org/ob-core.el:1524 org-mode-hook ../org/ob-latex.el:101 org-babel-latex-end-env ../org/ob-latex.el:79 org-babel-latex-preamble ../org/ob-latex.el:90 org-babel-latex-begin-env ../org/ob-python.el:208 python-shell-first-prompt-hook ../org/ol-bibtex.el:268 org-bibtex-headline-format-function ../org/org-compat.el:1272 imenu-after-jump-hook ../org/org-compat.el:1276 org-mode-hook ../org/org-compat.el:1339 speedbar-visiting-tag-hook ../org/org-crypt.el:317 org-mode-hook ../org/org-ctags.el:196 org-mode-hook ../org/org.el:15220 after-save-hook ../org/org.el:18651 occur-mode-find-occurrence-hook ../org/org-mouse.el:866 org-mode-hook ../org/ox-ascii.el:378 org-ascii-format-drawer-function ../org/ox-html.el:657 org-html-format-drawer-function ../org/ox-latex.el:888 org-latex-format-drawer-function ../org/ox-odt.el:635 org-odt-format-drawer-function ../org/ox-texinfo.el:334 org-texinfo-format-drawer-function ../pcomplete.el:305 pcomplete-command-completion-function ../pcomplete.el:315 pcomplete-default-completion-function ../play/gametree.el:118 gametree-make-heading-function ../progmodes/cperl-mode.el:1848 add-log-current-defun-function ../progmodes/octave.el:607 fill-nobreak-predicate ../progmodes/ps-mode.el:108 ps-mode-print-function ../vc/add-log.el:1129 fill-nobreak-predicate ../vc/emerge.el:2086 temp-buffer-show-function ../vc/smerge-mode.el:1358 ediff-quit-hook ../window.el:6662 pop-up-frame-function .. Additionally there are about 29 instances in the doc strings where users are urged to use lambda functions (rather than defuns) for this purpose. They are at: ../calendar/calendar.el:395 calendar-move-hook ../calendar/cal-tex.el:154 cal-tex-hook ../comint.el:189 comint-mode-hook ../dired-loaddefs.el:646 dired-mode-hook ../dired-x.el:152 dired-mode-hook ../erc/erc-log.el:218 erc-enable-logging ../erc/erc-page.el:55 erc-page-function ../files.el:466 auto-save-visited-predicate ../font-lock.el:704 c-mode-hook ../gnus/gnus-sum.el:1044 gnus-select-group-hook ../gnus/nnmail.el:179 nnmail-expiry-wait-function ../gnus/nnmail.el:286 nnmail-read-incoming-hook ../gnus/nnmail.el:299 nnmail-read-incoming-hook ../icomplete.el:154 icomplete-minibuffer-setup-hook ../ido.el:890 ido-minibuffer-setup-hook ../ielm.el:63 ielm-mode-hook ../ldefs-boot.el:29820 sql-mode-hook ../ldefs-boot.el:5069 c-mode-hook ../loaddefs.el:29950 sql-mode-hook ../loaddefs.el:5069 c-mode-hook ../obsolete/nnir.el:415 nnir-notmuch-filter-group-names-function ../org/org-keys.el:688 org-use-speed-commands ../org/ox-html.el:968 org-html-table-row-open-tag ../progmodes/compile.el:885 c-mode-hook ../progmodes/prog-mode.el:296 emacs-lisp-mode-hook ../progmodes/sql.el:4134 sql-mode-hook ../progmodes/sql.el:4256 sql-interactive-mode-hook ../textmodes/tildify.el:156 tildify-foreach-region-function ../transient.el:278 transient-substitute-key-function .. Furthermore there are, perhaps, around 150 such settings of ordinary defvars or defconsts to lambda functions. ######################################################################### I see two ways to fix this bug: (i) Systematically to replace each of these lambda functions by a named defun. (ii) To adopt git branch feature/named-lambdas, which attaches to every lambda function the name of the defun (or defvar) in which it was defined. This extra information could then be printed out for C-h v, something like this: Its value is {isearch-fold-quotes-mode} #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_109> Original value was nil Local in buffer *info*<3>; global value is nil , thus enabling the user quickly to locate the source of the lambda form in isearch.el. -- Alan Mackenzie (Nuremberg, Germany).
Alan Mackenzie <acm@HIDDEN>
:bug-gnu-emacs@HIDDEN
.
Full text available.bug-gnu-emacs@HIDDEN
:bug#66750
; Package emacs
.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.