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.