GNU bug report logs - #71934
31.0.50; edebug--called-interactively-skip vs. new fun objects

Previous Next

Full log

Message #22 received at 71934-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 71934-done <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>
Subject: Re: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new
 fun objects
Date: Fri, 05 Jul 2024 07:06:44 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I already did.

What about `which-key--get-keymap-bindings-1'?


For this one I CC Alan M.:

> There's one case on `comp.el` which may require some update

Yes, that's more or less the only other one I found:
`comp--spill-lap-function'.  Alan, we are discussing how relevant the
code in that function is that checks for lambda and closure cars, and if
it must be updated to handle the new interpreted function objects.

> but I don't understand the code enough to know what it intends to
> do.  It seems to match both `lambda` and `closure`, hence function
> *values*, but somehow it doesn't try and handle byte-code functions
> which are far more common function values, so maybe the `closure` is
> just irrelevant and the code is expected to match source code
> expressions (whose evaluation will return functions)?

Dunno.  `comp-trampoline-compile' constructs a lambda form to compile.
But never a "closure form".  So maybe irrelevant to check for 'closure'
indeed.

Alan had added the 'closure' symbol in

06e4ebc81a4 "With `native-compile', compile lambdas in a defun or lambda too"

which seems had been a fix for bug#64646 "Master: Native compiler
doesn't always compile lambda".  Guess this bug report is also an answer
to Stefan's question.



Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.