GNU bug report logs -
#71934
31.0.50; edebug--called-interactively-skip vs. new fun objects
Previous Next
Full log
Message #25 received at 71934-done <at> debbugs.gnu.org (full text, mbox):
> Cc: 71934-done <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>
> Date: Fri, 05 Jul 2024 07:06:44 +0200
> From: Michael Heerdegen via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> 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.
Andrea, can you take a look at this, please?
This bug report was last modified 314 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.