GNU bug report logs - #65344
28.2; Unable to Edebug cl-flet form which uses argument destructuring

Previous Next

Package: emacs;

Reported by: Brandon Irizarry <brandon.irizarry <at> gmail.com>

Date: Wed, 16 Aug 2023 18:23:02 UTC

Severity: normal

Found in version 28.2

Fixed in version 30.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log

Message #47 received at 65344 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: brandon.irizarry <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 65344 <at> debbugs.gnu.org
Subject: Re: bug#65344: 28.2; Unable to Edebug cl-flet form which uses
 argument destructuring
Date: Sun, 20 Aug 2023 07:32:50 +0200

[Message part 1 (text/plain, inline)]
On 20.08.23 05:57, Michael Heerdegen wrote:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
>> (debug ((&rest [&or (&define [&name symbolp "@cl-flet@"]
>> 			[&name [] gensym] ;Make it unique!
>> 			cl-lambda-list
>> 			cl-declarations-or-string
>> 			[&optional ("interactive" interactive)]
>> 			def-body)
>> 		    (&define [&name symbolp "@cl-flet@"]
>> 			[&name [] gensym] ;Make it unique!
>> 			def-body)])
> 
>> The second &define is for the (FN EXPR) bindings.  It comes after the
>> &define for "normal" function bindings because because, for some
>> reason, apparently the second &define also matches the other case.
> 
> That's because you use 'def-body' which matches any number of body
> expressions.  I think this is not correct: we are expecting a single
> form.

Ah, I see.  Thanks.

> 
> Apart from that: yes, something like this... I did not yet understand
> the &name magic.
> 
> And i wonder whether we should apply the distributive law and factor out
> the first few identical specs inside the &or.

I'd rather keep the two separate, I must admit.  Basically, bacause the 
first case it the important one, and the second I find obscure.

I also checked now what's up with functions whose name is (setf ...), 
which is valid CL.  That's not supported in ELisp, it seems, so I 
changed the debug spec of cl-defun accordingly in the attached patch.

If this looks good, I'd bring that to master, unless Eli wants it in 29.
[flet.patch (text/plain, attachment)]
This bug report was last modified 1 year and 261 days ago.

Previous Next

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